Plácido Antônio de Souza Neto. JCML - Java Card Modeling Language: Definição e Implementação.

(1)

Plácido Antônio de Souza Neto

JCML -

Java Card Modeling Language: Definição e

Implementação.

Natal

(2)

Universidade Federal do Rio Grande do Norte

Centro de Ciências Exatas e da Terra

Departamento de Informática e Matemática Aplicada

Programa de Pós-Graduação em Sistemas e Computação

JCML -

Java Card Modeling Language: Definição e

Implementação.

Exame de qualificação submetido ao Programa de Pós-Graduação em Sistemas e Computação do Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte como parte dos requisitos para a obtenção do grau de Mestre em Sistemas e Computação (MSc.).

Orientação: Profa. Dra. Anamaria Martins Mo-reira

Plácido Antônio de Souza Neto

(3)

Resumo

Este trabalho tem como objetivo apresentar uma proposta de um verificador runtime JML para o tecnologia Java Card. A tecnologia Java Card permite que smart cards e outros dispositivos com memória limitada rodem pequenas aplicações. Devido a esta limitação de memória, a estrutura da linguagem JML atual impossibilita uma verificação runtimede especificações pré-definidas. A solução aqui proposta consiste na definição e criação de um compilador, a partir de um subconjunto inicial da linguagem JML, para gerar código verificável em tempo de execução para programas escritos em Java Card.

Área de Concentração: Engenharia de Software Palavras-chave: . . .

(4)

Abstract

. . .

Area of Concentration: Software Engineering Key words: . . . .

(5)

Sumário

1 Introdução 8 1.1 Motivação . . . 8 1.2 Objetivos . . . 8 1.3 Organização do Trabalho . . . 8 2 Smart Card 9 2.1 Tecnologia Java Card . . . 10

2.1.1 Arquitetura Java Card . . . 14

2.2 AppletsJava Card . . . 15

2.3 Memória . . . 16

3 JML - Java Modeling Language 17 3.1 Design by Contract . . . 17

3.2 Estrutura da Linguagem JML . . . 19

3.3 Ferramentas JML . . . 22

3.3.1 Esc/Java . . . 23

3.3.2 jmlunit - Testes unitários com JML . . . 23

3.3.3 LOOP . . . 23 4

(6)

3.3.4 Jack . . . 24

3.3.5 jmlc - JML Compiler . . . 24

3.4 Runtime Checking . . . 25

3.5 Especificação JML para JavaCard . . . 27

4 Proposta 30 4.1 JCML - Java Card Modeling Language . . . 31

4.2 Metodologia . . . 31

4.3 Etapas de desenvolvimento da dissertação . . . 31

4.4 Cronograma de atividades . . . 31 5 Considerações Finais 33

(7)

Lista de Figuras

2.1 Smart Card. . . 9

2.2 Tecnologia Java Card. . . 11

2.3 JCVM - Java Card Virtual Machine. . . 12

2.4 Desenvolvimento Java Card- off-card. . . 13

2.5 Desenvolvimento Java Card- on-card. . . 14

2.6 Arquitetura Java Card. . . 14

2.7 Ciclo de Vida de um Applet. . . 16

3.1 Especificação JML em código Java. . . 22

3.2 Abordagem Wrapper - Controle de Fluxo. . . 26

3.3 Especificação JML em código Java Card [17]. . . 28

(8)

Lista de Tabelas

4.1 Cronograma de atividades para a elaboração da dissertação. . . 32

(9)

Capítulo 1

Introdução

1.1 Motivação

1.2 Objetivos

1.3 Organização do Trabalho

8

(10)

Capítulo 2

Smart Card

Um smart card (cartão inteligente) é um computador [12]. Apensar de não incluir teclado ou monitor, um smart card tem os elementos que caracterizam um computador. Um smart card é semelhante a um cartão de crédito convencional, contudo, tem uma pequena placa de metal em sua parte inferior responsável pelo contato do cartão com o dispositivo.

Os smart cards (ver Figura 2.1 são padronizados para a indústria pela ISO (Internation Organization Standardization) 7816 e suas sete partes, que definem características físi-cas, dimensões e localização de contatos, sinais eletrônicos e protocolos de transmissões. Chen [4] cita as seguintes especificações para smart card: GSM (Global System for Mo-blie Communication), EMV (Europay, MasterCard e Visa), Open Plataform, Global Pla-taform, Open Card Framework e PC/SC, assim como, o Java Card é uma especificação para smart card.

Os smart cards são conhecidos como cartões de chip ou cartões de circuitos integra-dos, tem estrutura de plástico que contém um microprocessor ou um chip de memória

Figura 2.1: Smart Card. 9

(11)

CAPÍTULO 2. SMART CARD 10 integrado. Segundo Chen [4], os cartões com apenas chip de memória podem não ser considerados como um cartão inteligente, já que realiza nenhum tipo de processamento, realizando funções pré-definidas.

Smart cards são usáveis quando aplicado a segurança de dados pessoais e mobilidade [12]. Os benefícios dos smart cards, estão ligados a: interoperabilidade, segurança, ca-pacidade de múltiplas aplicações, compatibilidade com padrões existentes e dinamismo [20].

A tecnologia Java Card é um adaptação da plataforma Java para ser utilizada em smart cards e outros dispositivos cujos ambientes tem a memória e restrições de pro-cessamento limitada. A tecnologia Java Card possui sua propria máquina virtual, API (Application Programming Interface) [20] e especificação de Runtime [27].

2.1 Tecnologia

Java Card

A tecnologia Java Card foi desenvolvida a partir de um subconjunto da linguagem Java, dessa forma a maquina virtual Java Card suporta apena as propriedades que são requeri-das pelo subconjunto da linguagem [4].

O desafio da tecnologia Java para smart cards é fazer com que a estrutura da lin-guagem Java seja utilizada para desenvolver sistemas que rodem em cartões, contudo é necesário conservar um espaço de memória considerável para que a aplicação seja com-patível com os padrões dos smart cards.

O Java Card permite que os smart cards e outros dispositivos com memória limi-tada rodem pequenas aplicações chamadas applets [4]. O smart card oferece plataforma independente, habilidade para guardar e atualizar múltiplas aplicações e compatibilidade com os padrões existentes dos smart cards. A tecnologia Java Card é compativel com os padrões de smart cards existentes (ISO 7816 Smart Card Standards). A tecnologia Java Card é representada na Figura 2.2.

Os componentes da tecnologia Java Card são:

• JCVM (Java Card Virtual Machine) : define um subconjunto da linguagem Java e a adapta as aplicações no smart card [28].

(12)

CAPÍTULO 2. SMART CARD 11

Figura 2.2: Tecnologia Java Card.

• JCRE (Java Card Runtime Environment) : define como se comporta o ambiente de execução, incluindo gerenciamento de memória, de aplicações, reforço de segu-rança e outras características da execução [27].

• JC-API (API Java Card) : descreve a interface de desenvolvimento de aplicações da tecnologia Java Card. A API também é compatível com os padrões interna-cionais já citados. A API contém definições de classe que são necessárias para o suporte da JCVM e JCRE [4].

A JCVM é uma Máquina Virtual Java dedicada, de uma única thread. A má-quina virtual Java Card não dá suporte a: Carregamento de classes dinâmicas, String e threads; Variáveis do tipo Double, Float e char, arrays multidimensionais; Classe java.lang.System; Garbage collection.

A JCRE consiste dos componentes do sistema Java Card que rodam dentro de um smart card. A propriedade mais significante da JCRE é que esta provê uma separação clara entre o sistema smart card e as aplicações desenvolvidas. A JCRE encapsula os detalhes da complexidade do sistema smart card, facilitando o desenvolvimento de aplicações.

A principal diferença entre a JCVM e a JVM (Java Virtual Machine) é que a JCVM é implementada como duas partes separadas, o conversor e o interpretador. O conversor Java Card (Figura 2.1) é executado em qualque estação de trabalho. O conversor faz

(13)

Figura 2.3: JCVM - Java Card Virtual Machine.

parte da estrutura off-card, que é quando o cartão não está em execução. Após a criação do arquivo CAP (Converted Applet - Seção 2.2), a verificação é feita pelo interpretador quando o smart card estiver em contato com a aplicação. O interpretador reconhece o arquivo CAP gerado pelo conversor. O interpretador é responsável pela validade da apli-cação no momento que esta é executada.

A JCVM utiliza dois tipos de arquivos, independente de plataforma, que são utiliza-dos no desenvolvimento de um software Java Card, são eles: Arquivos CAP (Converted Applet) e Arquivos Export. O CAP contém uma repesentação binária das classes exe-cutáveis Java (arquivos .class). Os arquivos CAP são como arquivos JAR que contém um conjunto de componentes. Cada arquivo CAP contém: informações de classes, by-tecodes executáveis e informações de verificação, como tipos de dados e visibilidade. Após a construção dos arquivos CAP (off-card), estes são inseridos no cartão para serem executados (on-card) como mostra a Figura 2.1.

O arquivo Export não é executado pelo interpretador. Este arquivo é utilizado pelo conversor para a verificação da estrutura Java Card [4]. Este arquivo contém informações de APIs públicas de um pacote de classes. Com isso é definido o tipo de acesso e nomes das classes. Também é definido neste arquivo, o escopo de acesso e assinatura de métodos e atributos da cada classe. O arquivo Export não contém nenhuma implementação, com isso não possui bytecodes. Este arquivo pode ser distribuído pelos desenvolvedores Java Card sem revelar detalhes de implementação. o arquivi export pode ser comparado com uma interface de comunicação Java, onde nela é definido a estrutura da classe.

As Figuras 2.4 e 2.5 apresentam os passos para desenvolvimento dos componentes necessários para um Java Card [21]. A Figura 2.4 mostra a seguencia de passos off-card,

(14)

Figura 2.4: Desenvolvimento Java Card- off-card.

onde os arquivos CAP e Export são definidos. A Figura 2.5 apresenta a estrutura on-card, onde através dos comandos APDU a aplicação Java Card é inserida no cartão.

Os passos para o desenvolvimento de uma aplicação Java Card são: • Escrever o Applet Java Card;

• Compilar o Applet;

• Testar o Applet Java Card com o simulador JCWDE (tarefa opcional);

• Converter as classes geradas em um arquivo CAP, usando a ferramenta de conversão. Opcionalmente os arquivos Export são adicionados para prover infor-mações sobre os pacotes e classes;

• Verificar o arquivo CAP;

(15)

Figura 2.5: Desenvolvimento Java Card- on-card.

Figura 2.6: Arquitetura Java Card.

2.1.1 Arquitetura

Java Card

Os principais componentes de uma JavaCard são o microprocessador e as memórias. A arquitectura básica de uma JavaCard consiste em: Applets, Java Card API, Java Card Virtual Machine (JCVM) / Java Card Runtime Environment(JCRE), e o sistema opera-cional nativo do cartão.

A máquina virtual que é executada sobre o sistema operacional do cartão, pode ser vista como uma abstração. Sobre a máquina virtual encontra-se o Java Card Framework, que é um conjunto de classes necessárias para o funcionamento do JCRE e a Java Card API, como também as classes ou extensões proprietárias do fabricante do cartão. No topo encontram-se os applets que utilizam todos os demais componentes.

(16)

2.2 Applets

Java Card

Os applets Java Card são classes Java que estendem a classe java-card.framework.Applet, seguindo as especificações da tecnologia Java Card [4]. A comunicação entre o applet e uma aplicação host ocorre através de várias mensagens APDU (Application Protocol Data Unit). Essas mensagens são pacotes de dados lógicos trocados entre o dispositivo de leitura e o cartão.

Todo applet Java Card deve executar os métodos install() e process(); o JCRE (Java Card Runtime Environment) [27] chama o método install() para instalar o applet, e o método process() cada vez que é enviado um comando da APDU para o applet [22].

As classes e os applets Java Card são empacotados em um único arquivo denominado CAP (Converted Applet), semelhante a um arquivo Jar (Java Archive), e esse arquivo é instalado no cartão.

O ciclo de vida de um applet tem inicio ao ser carregado na memória do cartão, ao ser carregado o JCRE invoca o método install(), o applet registra-se no JCRE com o método register(); depois deste processo (instalação e registro) o applet está em estado “unselected” e em condições de execução . O applet normalmente existe durante o resto da vida do cartão. A Figura 2.2 apresenta os métodos do ciclo de vida de um applet.

(17)

Figura 2.7: Ciclo de Vida de um Applet.

2.3 Memória

Os smart cards tem 3 tipos de memória: • ROM;

• EEPROM; • RAM.

ROM é uma memória de leitura apenas. Dados e programas são armazenados na ROM durante a fabricação do smart card. No entanto, tanto a EEPROM quanto a memória RAM podem ser lidas e escritas, contudo essas memórias tem características diferentes. A conteúdo da memória RAM é preservado apenas quando o cartão está ativo, com potência para preservar os dados. Na memória EEPROM, os dados são preservados mesmo quando o cartão não esta em contato com a aplicação host, e não existe energia para deixar o cartão ativo. A memória RAM é mais rápida que a memória EEPROM. Os smart cards normalmente oferencem 1k de RAM, 16k EEPROM e 24k de ROM [4]. O processamento do cartão pode variar entre 5 e 40MHz dependendo do tipo de tecnologia do cartão.

(18)

Capítulo 3

JML - Java Modeling Language

JML é uma linguagem de especificação de interfaces que pode ser usada para formalizar o comportamento de módulos Java [13]. Usando JML é possivel especificar interfaces definidas em Java como também seus comportamentos. JML combina particularidades de linguagem DbC (Design by Contract), como Eiffel [18], e a abordagem de especi-ficação baseada em modelos [10]. JML usa a sintaxe Java para escrever os predicados, como Pré-Condição e Pós-Condição.

3.1 Design by Contract

Design by Contract (Projeto por Contrato) é o princípio pelo qual interfaces entre módu-los de software devem ser estruturadas utilizando especificações precisas [11]. Os contra-tos definem obrigações e benefícios mútuos (Pré-Condição e Pós-Condição respecti-vamente), e restrições (invariantes). Essas propriedades são conhecidas como asserções (assertions).

Asserções são representações de estados de um programa ou código. São expressões verdadeiras em determinados pontos de um código [5]. Assertivas são importantes quando se deseja provar a corretude de um programa. Para que seja possível provar a corretude de um determinado programa ou um trecho de código, é necessário definir expressões que possam garantir estados desejados. Se, a partir das asserções, determinadas propriedades não forem garantidas quando o programa for executado, algo de errado ocorreu, seja com a assertiva definida ou a propria definição do programa.

(19)

CAPÍTULO 3. JML - JAVA MODELING LANGUAGE 18 Meyer propôs, em seu trabalho sobre Design by Contract [19], simples asserções para linguagem Eiffel [18]. Sua idéia era usar tais assertivas para definir contrato entre os módulos do programa, da mesma forma, àqueles que usariam os módulos (clientes).

Design by Contract também pode ser visto como um método de desenvolvimento de software em que promove um contrato explícito entre as classes e seus clientes [19]. Nele, o cliente deve garantir certas condições prévias antes de chamar um método da classe, que por sua vez, deve garantir alguns benefícios após ser executado. Esses contratos são definidos e compilados juntamente com o próprio código do programa, garantindo assim, que qualquer violação do contrato, que aconteça durante a execução do programa, seja detectado [13].

Os benefícios [9] de se utilizar Design by Contract incluem:

• Melhor entendimento do método Orientado a Objetos e, de uma forma mais geral, da construção de software;

• Uma abordagem sistemática de construir sistemas Orientado a Objetos sem bugs; • Um framework que facilite a depuração, teste e proporcione garantia de qualidade

ao produto desenvolvido;

• Um método para documentar componentes de software; • Melhor entendimento e controle dos mecanismos de herança.

Cada asserção é uma lista de expressões booleanas separadas por um identificador1. Um contrato é escrito logo antes do cabeçalho do método, tipicamente especificando uma Pré-Condição e uma Pós-Condição, onde a Pré-Condição de um método diz o que deve ser verdade para que ele possa ser executado e a Pós-Condição diz o que deve ser verdade quando o método terminar sua execução. Existem dois tipos de Pós-Condição, as normais e as excepcionais. As normais são as que dizem o que deve ser verdade quando o método retorna normalmente, isto é, sem lançar uma exceção, enquanto

1_{Os identificadores de separação podem variar, dependendo da linguagem. Na linguagem Eiffel [18] é} utilizado o identificador [;], em JML é utilizado o identificador [&&]. Os identificadores que separam as expressões é equivalente a cláusula and booleana.

(20)

CAPÍTULO 3. JML - JAVA MODELING LANGUAGE 19 que, as excepcionais definem o que deve ser verdade quando o método lançar uma exce-ção.

DbC é uma forma de definir responsabilidades aos métodos, podendo ser usado para determinar as chamadas, como também para especificar os efeitos das chamadas dos mes-mos. Uma outra vantagem de DbC é que pode ser usado para atribuir culpa a uma parte defeituosa de um programa. Assim, caso uma Pré-Condição seja violada, a culpa será atribuída ao cliente, semelhantemente, caso uma Pós-Condição seja violada, a culpa será do método fornecedor do serviço [13].

O uso de DbC proporciona uma boa documentação para as classes e interfaces Java. Design by Contract é melhor para documentação do que comentários de programa, do-cumentação informal e até mesmo comentários de Javadoc. Isto ocorre pelo fato de ape-nas especificar o que deve ser adotado e no que deve ser definido para garantir algumas propriedades.

A especificação resume os detalhes de implementação. Isto significa que a imple-mentação pode ser mudada sem invalidar o código do cliente. Contudo, o novo código deve ainda satisfazer o contrato. Um contrato é uma abstração do comportamento de um método.

3.2 Estrutura da Linguagem JML

JML é uma linguagem fácil e acessível aos programadores Java. JML foi projetado para ser usado em conjunto com uma variedade de ferramentas. Essas ferramentas suportam Design by Contract (DbC), checagem em tempo de execução, descoberta de invariantes, verificação estática e verificação formal que usa provadores de teoremas. Tais ferramentas serão descritas na seção 3.3.

Gary Leavens [13] deu inicio ao desenvolvimento da JML, junto com estudantes e pesquisadores da Universidade de Iowa. Hoje, alguns grupos de pesquisa tem construído ferramentas que dão suporte a notação JML [3]. O esforço cooperativo para o desenvol-vimento de um padrão de especificação Java é importante tanto para desenvolvedores de ferramentas como para usuários [2].

(21)

CAPÍTULO 3. JML - JAVA MODELING LANGUAGE 20 O foco central de uma especificaçao JML são as Pré-Condição e Pós-Condição (para os métodos) e o invariante (para a classe). As asserções JML são escritas como um comentário especial Java. Os comentários são ignorados pelo compilador Java, mas podem ser usados pelas ferramentas que dão suporte ao JML [3]. Tais comentários exten-dem a sintaxe Java, adicionando algumas palavras chaves (reservadas). Dentre algumas palavras reservadas, têm-se: invariante, requires, assignable, ensures, signals; e algumas operações como: \forall, \exists e \result [14].

A JML permite especificar tanto a interface do código Java como seu comportamento. A interface consiste de nomes, visibilidade e outros modificadores e informações sobre type checking [13]. Por exemplo, a interface pode ser vista no cabeçalho do método com uma lista de modificadores, seus referentes nomes, tipo de retorno e exceções (caso seja possível serem lançadas). O comportamento do código descreve o que pode acontecer em tempo de execução, quando o código é usado. Ou seja, o comportamento de um método descreve o que deve acontecer quando o método é chamado. Este comportamento é frequentemente especificado usando as Pré-Condição e Pós-Condição, como citado anteriormente.

A especificação JML é escrita na forma de comentários Java (Annotation) onde tem como marca inicial da especificação //@, ou marcações entre /*@. . . @*/.

Uma simples especificação JML consiste em métodos especificados com Pré-Condição, Pós-Pré-Condição, marcados pelas cláusulas @requires e @ensures respecti-vamente; e pela Invariante de classe - invariant, verificando os estados do objeto.

Uma especificação de um método pode conter Pós-Condição excepcional, onde são anotadas pelas cláusulas signals ou exsures. Uma Pós-Condição excepcional define que condição deve ser satisfeita caso o método termine abruptamente, lançando uma exceção. A especificação de um método pode conter uma cláusula que defina quais variáveis podem ser modificadas em uma chamada de método. A notação em JML é modifies, assignable ou modifiable. A cláusula assignable, mais comumente utilizada, é importante quando se faz verificação modular de programa [2].

A cláusula constraint é utilizada quando se necessita restringir os possíveis estados do objeto. Esta cláusula denota uma relação entre a Pré-Condição e pós-estado do método,

(22)

CAPÍTULO 3. JML - JAVA MODELING LANGUAGE 21 restringindo como a variável pode ser modificada. Por exemplo, pode-se definir que uma variável é constante ou que a mesma pode apenas receber valores maiores que o atual atribuído. Todos os métodos em classes que herdam de uma classe que contém a cláu-sula invariant ou constraint devem respeitar a especificação de tais cláucláu-sulas definidas na classe herdada. A cláusula que define que a especificação de uma classe pai é herdade é a cláusula also.

Existe uma cláusula que refere o valor de retorno do método - \result. Esta cláusula deve ser usada apenas dentro da cláusula ensures. Outra expressão muito utilizada em especificações JML é \old(), que faz referência a um pré-estado de uma variável, como por exemplo: \old(var1) <= var1; Define que ao término de uma rotina (método), o valor da variável var1 é maior ou igual ao seu valor inicial no início da rotina.

JML incorpora os quantificadores universal (\forall) e existencial (\exists) como cláu-sulas da linguagem. A sintaxe na cláusula (\exists) é semelhante ao (\forall).

A JML ainda possue outras cláusulas que auxiliam no processo de especificação de software. Tais cláusulas podem ser vista com detalhes em [14] e [5]. O código a seguir apresenta um código genérico de uma classe Java especificada com anotacões JML.

A Figura 3.2 apresenta a estrutura de uma especificação JML em uma classe Java. Na linha 1 é definida a classe Java. Nas linhas 3 e 4 são definidas 2 variáveis, e 2 va-lores quaisquer são atribuídos. A cláusula spec_public define as variáveis como públicas no contexto da especificação, mesmo que a sua Visibilidade seja privada ao contexto da classe. Entre as linhas 6 e 8, o invariante de classe é definido. As expressões nesta cláu-sula devem ser respeitada no escopo de toda a classe. Entre as linhas 10 e 17 é descrita a estrutura da especificação JML. As cláusulas utilizadas neste exemplo são: requires, modifies, ensures, signals. A cláusula requires define a Pré-Condição para o método ser executado. A cláusula modifies especifica quais variáveis que podem sofrer modificações no escopo do método, neste caso, apenas a variavel1 pode ter seu valor modificado. As duas últimas cláusulas dizem respeito ao pós-estado das variáveis. A cláusula ensures define as expressões que devem ser verdadeiras ao final da execução do método, enquanto a cláusula signals define os valores das variáveis ao final de uma exceção, caso esta seja lançada. Por fim, entre as linhas 18 e 24 é definido o método. É importante notar que antes do condifional na linha 19, nenhuma operação foi realizada, contudo, mesmo se o

(23)

CAPÍTULO 3. JML - JAVA MODELING LANGUAGE 22

1 public class NomeDaClasse{

2

3 /*@ spec_public @*/ Visibilidade TipoVariavel variavel1 = valor;

4 /*@ spec_public @*/ Visibilidade TipoVariavel variavel1 = valor;

5

6 /*@ invariant E1 && E2 && ..

7 @ && En;

8 @*/

9

10 /*@

11 @ requires E1 && .. & En;

12 @ modifies variavel1;

13 @ ensures E1 && .. & En;

14 @ signals (Exception e)

15 @ atributo2 < 0 &&

16 @ variavel1 == \old(variavel1);

17 @*/

18 public <retorno> <nomeMétodo>(atributo1, .., atributoN) throws Exception{

19 if(atributo2 < 0) 20 Exception.throwIt(Exception.OVERFLOW); 21 22 atributo1 == atributo2 * 3; 23 return .. ..; 24 } 25 }

Figura 3.1: Especificação JML em código Java.

atributo2 for menor que zero, a especificação será satisfeita, pois não foi atribuído va-lor algum a variavel1, permanecendo o vava-lor desta variável, o mesmo antes do início do método (\old(variavel1)) e o atributo2 permanecerá menor do que zero.

3.3 Ferramentas JML

Para uma linguagem de especificação, da mesma forma que para uma linguagem de pro-gramação, algumas ferramentas são necessárias para suprir as necessidades dos usuários da linguagem, como leitura, escrita, checagem de tipos e checagem da notação JML [3].

Existem algumas ferramentas que dão suporte a JML. Tais ferramentas tem carac-terísticas distintas, como verificação estática, identificação de invariante a partir da es-pecificação, testes unitários, checagem em tempo de execução e ferramentas que geram documentação.

(24)

3.3.1 Esc/

Java

A ferramenta ESC/Java [15] faz verificação estática a partir da especificação e foi de-senvolvida pela Compaq Systems Research Center. A ferramenta pode checar simples assertivas e pode checar alguns tipos de erros comuns no código Java, como referência nula ou index de arrays fora do limite. A ferramenta é totalmente automatizada. O prova-dor de teoremas fica oculto ao usuário, ficando apenas como interface principal o sintaxe JML.

O ESC/Java funciona traduzindo um programa Java anotado com JML em condições de verificação, onde são repassados para um provador automático de teoremas. Existe diferença em relação a sintaxe e semântica do JML e um subconjunto do JML utilizado em ESC/Java.

3.3.2 jmlunit - Testes unitários com

JML

A ferramenta jmlunit [6], desenvolvida pela Universidade de Iowa, faz com que o progra-mador não se preocupe em escrever excessivos códigos de teste unitário, simplesmente automatizando os testes unitários das interfaces e classes Java.

A ferramenta gera classes de teste Junit. As classes de teste enviam mensagens para os objetos Java em teste. O código de teste recupera erros de violação das asserções. As classes de teste verificam se o método que esta sendo testado satisfaz as condições estabe-lecidas na especificação. No entanto, quando um método que está sob teste satisfaz a pré condição, mas por outro lado tem uma asserção violada, a implementação não satisfaz a especificação. Dessa forma, os dados de teste detectam uma falha.

3.3.3 LOOP

A ferramenta LOOP [30], desenvolvida na Universidade de Nijmegen - Holanda, traduz código Java anotado com JML em obrigações de prova para o provador de teoremas PVS [26]. O LOOP permite verificação de propriedades mais complicadas que o ESC/Java. Uma ferramenta similar de verificação de programas para código anotado com JML sob desenvolvimento é a ferramenta Krakatoa [16]. Esta ferramenta produz obrigações de

(25)

CAPÍTULO 3. JML - JAVA MODELING LANGUAGE 24 prova para o provador de teoremas Coq [8], mas no momento da suporte apenas a um subconjunto Java.

3.3.4 Jack

A ferramenta JACK foi desenvolvida pelo laboratório de pesquisa da Gemplus. JACK tem como objetivo prover um ambiente de desenvolvimento para verificação de progra-mas Java e Java Card utilizando anotações JML. As obrigações de prova do JACK são geradas pelo provador de métodos B [1].

A proposta da ferramenta JACK é algo entre o ESC/Java e o LOOP, sendo mais próxima da ferramenta LOOP que do ESC/Java, tentando utilizar o melhor das duas fer-ramentas. Um importante objetivo da ferramenta é ser usável para programadores Java. A ferramenta provê uma interface para provador automático de teoremas Atelier B [7].

Apesar de usar técnicas formais, o objetivo da ferramenta JACK não é apenas permitir que sejam provadas corretude de applets Java, mas sim permitir a programadores Java uma maior segurança da corretude do código.

3.3.5 jmlc -

JML Compiler

O compilador JML é uma extensão do compilador Java, onde além de compilar o código Java, verifica as asserções JML. O compilador bytecode inclui verificação runtime das instruções que checa a especificação JML como pré condições, pós condições normais e com exceções e invariantes.

O compilador JML traz alguns benefícios para especificação de intefaces formais, permitindo ao programador Java usar JML como ferramenta de debugging, teste e design by contract.

O compilador JML, como o compilador Java, produz o byte-code do código-fonte, porém, adiciona a declaração que verifica o código. Outra semelhança é que ambos são utilizados da mesma forma, vindo antes do nome do arquivo que se deseja compilar.

(26)

CAPÍTULO 3. JML - JAVA MODELING LANGUAGE 25 gerado pelo Java, a não ser que precise das classes de biblioteca de runtime de JML incluídas em jmlruntime.jar para ser interpretado pela Java Máquina Virtual.

3.4 Runtime Checking

Desenvolver uma estrutura para verificar código de especificação em tempo de execução é uma tarefa que tem como objetivo apresentar sua viabilidade e eficiência quando aplicada a programação. Um requisito essencial na verificação runtime é a transparência, pois o comportamento do programa original escrito não pode modificar. A especificação deve garantir estados finais a determinadas variáveis, caso algum problema ocorra, ou uma ex-ceção seja lançada. Outro fator a ser levado em consideração é a semântica da linguagem (JML), pois é importante que o código da especificação reflita realmente o que necessita ser representado. Por fim, a verificação runtime deve detectar erros a partir das assertivas. Yoonsik Cheon [5] definiu o verificador runtime para JML. Em sua tese é utilizada uma abordagem para traduzir a especificação em métodos privados (private) que são cha-mados pelos métodos “especificados”, para que a especificação seja garantida em tempo de execução.

A tradução da especificação JML em código para verificação runtime é feita em 3 passos conceituais.

1. Simplificar a especificação JML em uma forma que facilite a tradução. Esta tarefa identifica e extrai asserções executáveis dos métodos que contém especificação. A parte principal da simplificação é transformar o uso de Açucar Sintático2 _{em uma} forma ainda mais simples [25].

2. Traduzir as asserções simplificadas em código runtime.

3. Adicionar o código gerado no código original. Este passo insere o código de veri-ficação runtime no local apropriado no código original. Por exemplo, o código da pré e da pós-condição devem ser executados antes e após a execução do corpo do método.

2_{Açucar Sintático é o fato de produzir um programa com uma sintaxe mais simples. Açucar Sistático} proporciona ao programador um caminho alternativo de programação que é mais prático. Sendo mais sucinto ou com uma notação familiar. Açucar Sintático é um termo inventado por Peter J. Landin.

(27)

CAPÍTULO 3. JML - JAVA MODELING LANGUAGE 26 Figura 3.2: Abordagem Wrapper - Controle de Fluxo.

Existem 2 abordagens para inserir o código runtime no código original. A abordagem in-linee a abordagem wrapper. O compilador JML utiliza a abordagem wrapper por jul-gar ser melhor estruturada e organizada para o contexto da linguagem [5]. Na abordagem wrappero código gerado é modularizado e utiliza métodos de verificação a partir das pré e pós-condições e outras assertivas JML.

Na abordagem in-line, o código de verificação é inserido diretamente no corpo do método a ser checado. O código da pré-condição é a primeira indicação do corpo do método. Existem 2 desvantagens ao se utilizar está abordagem.

1. Não é trivial inserir código de verificação runtime em assertivas que tratam de um pós-estado como pós-condição normal e excepcional e invariantes. O código não pode ser inserido no final do corpo do método, pois o método pode retornar algum valor.

2. A abordagem in-line também não utiliza uma forma modular para implementação de herança. O código de gerado não é herdado pelas sub-classes, pelo fato do código ser inserido dentro do método [5].

Na abordagem wrapper, o código de verificação torna um método separado. Métodos para checar a pré e a pós-condição. O método wrapper é chamado quando os clientes utilizam o método original. Cada método pode lançar uma exceção, caso os parametros ou

(28)

CAPÍTULO 3. JML - JAVA MODELING LANGUAGE 27 retornos não satisfaçam a especificação do método. Esta abordagem facilita a utilização de herança em relação a especificação. A Figura 3.2 apresenta a estrutura da abordagem wrapper.

3.5 Especificação JML para JavaCard

Java Card é um bom foco para a aplicação de métodos formais, no caso específico o pro-jeto por contrato, por algumas razões: os applets de Java Card vem sendo utilizado em um número crescente a cada ano, usados frequentemente em aplicações críticas, de modo que os erros de programação possam ter conseqüências sérias. Porém, os applet de Java Card são geralmente programas pequenos, projetados para funcionar em um processador com recursos restritos. Também, a linguagem desses applets são relativamente simples, com uma API relativamente pequena, em comparação ao Java convencional. Isso faz à aplicação de métodos formais em Java Card algo praticável e útil, que possa ter efeitos satisfatórios [24].

Segundo Erik Pool [24], os contratos podem ser usados para especificar e verificar propriedades essenciais das execuções da API Java Card, e também checar propriedades dos applets individuais que usam a API.

O uso de JML em Java Card teve início com a especificação das proprias classes da API Java Card. A classe APDU [28], responsável pela comunicação da aplicação host e o applet cliente, teve a estrutura dos médotos definidos com anotações JML. Contudo tais especificações não são verificadas em tempo de execução. Algumas das ferramentas apre-sentadas na Seção 3.3 fazem uso de checagem estática das anotações JML para garantir algumas propriedades. Dessa forma, apesar de algumas propriedades serem garantidas com a verificação estática, as características da tecnologia JML não é aplicada em sua totalidade quando utilizada desta forma.

Após o esforço inicial com a classe APDU da API Java Card, toda a API Java Card foi anotada com JML no trabalho de Meijer [17]. Da mesma forma, tais caracteristicas da especificação não são garantidas em tempo de execução, pois as restrições Java Card não permitem que o código gerado a partir da compilação com a ferramenta jmlc (Ver Seção

(29)

1 /*@ public behavior

2 @ requires apdu != null;

3 @ requires apdu._APDU_state == 1;

4 @ requires (* apdu.getBuffer()[0..3] available *);

5 @ requires apdu._CLA == apdu.buffer[0];

6 @ requires apdu._INS == apdu.buffer[1];

7 @ requires apdu._P1 == apdu.buffer[2];

8 @ requires apdu._P2 == apdu.buffer[3];

9 @ assignable \everything;

10 @

11 @ ensures true;

12 @ signals (ISOException) true ; /// see JCRE spec, section 3.3

13 @ signals (APDUException) true ;

14 @*/

15 public abstract void process(APDU apdu)

16 throws ISOException, APDUException;

Figura 3.3: Especificação JML em código Java Card [17].

3.3) rodem em applets Java Card, pelo fato desta ferramenta adicionar características do Java SDK que não são defininas na especificação runtime Java Card [27].

Na Figura 3.5 é apresentado o método process da classe Applet anotado com JML. A classe Applet é herdada quando se deseja implementar um Applet Java Card.

Existem algumas restrições da versão atual do JML (5.4_rc1), com a API SDK do Java. Como a proposta da linguagem é em relação a tecnologia Java, existe uma cres-cente necessidade de viabilizar e melhorar a estrutura da JML, para se tornar compatível com a tecnologia proposta. A versão da API atual no Java Card (2.2) não utiliza alguns dos objetos gerados pelo compilador JML. Da mesma forma, a versão atual do Java (6.0), não é satisfeita com algumas estruturas da JML.

A especificação JML em Java Card é feita da mesma forma como é definida para a tecnologia Java, como apresentado na Figura 3.5, contudo, o código gerado não pode ser verificado.

Trabalhos como BML (ByteCode Modeling Language) [23] tem como objetivo mel-horar a definição JML para especificar sistemas. A BML tem como foco principal a imcompatibilidade de versões e tecnologias Java com a JML.

Será apresentado no Capítulo 4 uma proposta para definição de um sub-conjunto da JML para a tecnologia Java Card. Este trabalho tem como objetivo principal a tecnologia

(30)

CAPÍTULO 3. JML - JAVA MODELING LANGUAGE 29 Java Card e a verificação em tempo de execução das anotações JML.

(31)

Capítulo 4

Proposta

A tarefa principal a ser realizada para a dissertação é o desenvolvimento e a implementa-ção de uma estrutura que forneça à tecnologia Java Card a geraimplementa-ção de código a partir de uma especificação lightweight, inicialmente, para que as pré-condições sejam garantidas em tempo de execução.

Uma especificação lightweight é uma especificação que tem como foco a garantia da pré-condição dos métodos. É uma especificação incompleta, pois não se preocupa com o tratamento de exceções em tempo de execução.

O compilador JML, como o compilador Java, produz o byte-code do código-fonte, porém, adiciona a declaração que verifica o código. Como existem algumas diferenças entre a estrutura Java Card e a estrutura standard do Java, utilizar a estrutura atual do compilador JML pode gerar um erro (exceção) de runtime no Java Card, devido as restrições de memória. Com isso, a definição de um compilador JML para Java Card, a partir de um subconjunto já definido na linguagem JML, viabilizaria uma verificação das interfaces JML a serem implementadas para garantir o contrato em tempo de execução para as classes Java Card implementadas. A linguagem para definição dos contratos para Java Card será entitilada de JCML (Java Card Modeling Language).

Como o compilador JML, a JCML utilizará a abordagem wrapper, como descrita por Roy P. Tan [29] para geração do código. O objetivo principal desta abordagem é separar o código gerado, a partir da especificação, do código original. Esta separação consiste em classes ou métodos wrapper, que são chamados pelo método original para garantir as definições da especificacão.

(32)

CAPÍTULO 4. PROPOSTA 31 Paralelo a implementação, as pesquisas seguirão na busca por parâmetros para avaliar o trabalho aqui proposto. Serão buscados trabalhos relacionados ao tema trabalhado, com o objetivo de desenvolver uma melhor estrutura de verificação.

4.1 JCML -

Java Card Modeling Language

4.2 Metodologia

Para a elaboração da dissertação optou-se por pesquisas, leituras de artigos e encontros semanais com o orientador para direcionamentos sobre o tema.

4.3 Etapas de desenvolvimento da dissertação

O desenvolvimento da pesquisa e a elaboração da dissertação a que se propõe este tra-balho já está em andamento, e algumas tarefas já estam sendo realizadas. As atividades envolvidas na pesquisa e produção da dissertação são descritas a seguir:

1. 2. 3. 4. 5.

4.4 Cronograma de atividades

A tabela 4.1 mostra o cronograma das atividades que necessitam ser realizadas para a conclusão da dissertação.

(33)

CAPÍTULO 4. PROPOSTA 32

2006 2007

Set Out Nov Dez Jan Fev Março 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 ••

(34)

Capítulo 5

Considerações Finais

(35)

Referências Bibliográficas

[1] Jean-Raymond Abrial. The B Book: Assigning Programs to Meanings. Cambridge University Press, August 1996.

[2] Breunesse, Catano, Huisman, and Jacobs. Formal methods for smart cards: An experience report. SCIPROG: Science of Computer Programming, 55, 2005. [3] Lilian Burdy, Yoonsik Cheon, David R. Cok, Michael D. Ernst, Joseph R. Kiniry,

Gary T. Leavens, K. Rustan M. Leino, and Erik Poll. An overview of JML tools and applications. Int. J. Softw. Tools Technol. Transf., 7(3):212–232, 2005.

[4] Zhiqun Chen. Java Card technology for Smart Cards: architecture and program-mer’s guide. Java series. Addison-Wesley, pub-AW:adr, 2000.

[5] Yoonsik Cheon. A Runtime Assertion Checker for the Java Modeling Language. PhD thesis, April 2003. The author’s Ph.D. dissertation. Available from ar-chives.cs.iastate.edu.

[6] Yoonsik Cheon and Gary T. Leavens. A simple and practical approach to unit testing: The JML and JUnit way. In Boris Magnusson, editor, ECOOP 2002 — Object-Oriented Programming, 16th European Conference, Máalaga, Spain, Proceedings, volume 2374 of Lecture Notes in Computer Science, pages 231–255, Berlin, June 2002. Springer-Verlag.

[7] ClearSy. Atelier B, user and reference manuals. http://tinyurl.com/lkj72, 1996. [8] The Coq. The coq proof assistant : Reference manual : Version 7.2, February 2002. [9] Eiffel Software. Building bug-free O-O software: An introduction to Design by

Contract. URL: http://archive.eiffel.com/doc/manuals/technology/contract/. 34

(36)

REFERÊNCIAS BIBLIOGRÁFICAS 35 [10] J. Guttag and J. Horning. Larch: Languages and Tools for Formal Specification.

Springer-Verlag, Berlin, 1993.

[11] Jean-Marc Jézéquel and Bertrand Meyer. Design by contract: The lessons of ariane. IEEE Computer, 30(1):129–130, January 1997.

[12] Timothy M Jurgensen and Scott B Guthery. Smart Cards: A Developer’s Toolkit. Prentice Hall PTR, 2002.

[13] Gary T. Leavens and Yoonsik Cheon. Design by contract with JML. Draft, available from jmlspecs.org., 2006.

[14] Gary T. Leavens, Erik Poll, Curtis Clifton, Yoonsik Cheon, Clyde Ruby, David Cok, Peter Müller, Joseph Kiniry, and Patrice Chalin. JML Reference Manual, May 2006. Draft revision 1.193.

[15] K. Rustan M. Leino, Greg Nelson, and James B. Saxe. ESC/Java user’s manual. Technical note, Compaq Systems Research Center, October 2000.

[16] C. Marche, C. Paulin Mohring, and X. Urbain. The KRAKATOA tool for certi-fication of JAVA/JAVACARD programs annotated in JML. Journal of Logic and Algebraic Programming, 58(1–2):89–106, 2004.

[17] Hans Meijer and Erik Poll. Towards a full formal specification of the JavaCard API. Lecture Notes in Computer Science, 2140:165–??, 2001.

[18] Bertrand Meyer. Eiffel: The Language. Prentice Hall, 1991.

[19] Bertrand Meyer. Applying design by contract. IEEE Computer, 25(10):40–51, 1992. [20] Sun Microsystems. Java card technology overview. <http://java.sun.com/products/javacard/overview.html>, Acessado em julho de 2006.

[21] C. Enrique Ortiz. An introduction to java card technology - part 2, the java card ap-plet. <http://developers.sun.com/techtopics/mobility/javacard/articles/javacard2/>, 2003, Acessado em outubro de 2006.

(37)

REFERÊNCIAS BIBLIOGRÁFICAS 36 [23] Mariela Pavlova and Lilian Burdy. Java bytecode specification and verification. 21st

Annual ACM Symposium on Applied Computing, 2006.

[24] Erik Poll, Joachim van den Berg, and Bart Jacobs. Formal specification of the java-card API in JML: the APDU class. Computer Networks, 36(4):407–421, 2001. [25] Arun D. Raghavan and Gary T. Leavens. Desugaring JML method specifications.

Technical report, August 08 2000.

[26] N. Shankar. PVS: Combining specification, proof checking, and model checking. Lecture Notes in Computer Science, 1166:257–??, 1996.

[27] Sun Microsystems. Runtime Environment Specification - Java Card Platform, Ver-sion 2.2.2, 2005.

[28] Sun Microsystems. Virtual Machine Specification - Java Card Platform, Version 2.2.2, 2005.

[29] Roy Patrick Tan. Runtime assertion checking using JML, August 15 2003.

[30] Joachim van den Berg and Bart Jacobs. The LOOP compiler for java and JML. In Tiziana Margaria and Wang Yi, editors, TACAS, volume 2031 of Lecture Notes in Computer Science, pages 299–312. Springer, 2001.