O USO DE PROJETO POR CONTRATO E JML PARA O DESENVOLVIMENTO

DE SISTEMAS CONFIÁVEIS

Joanna de Cássia Rodrigues Valadares¹

Resumo: ​A interação homem-máquina gera cada vez mais o anseio por sistemas confiáveis e
acessíveis. Sendo assim, sabemos que proteger informação é um desejo inerente de qualquer
ser humano. Através disso, vale ressaltar que o gasto com tempo e dinheiro será excessivo
para que o desejo almejado seja alcançado. ​O presente projeto tem como intuito demonstrar
de forma prática através do desenvolvimento de classes, o uso da linguagem ​Java Modeling
Language​(JML), onde, JML trabalha com contratos e, usa a teoria ​projeto por contrato
(​Design by contract​) pra gerar afirmações que visa tornar os sistemas mais confiáveis.
Desenvolvida primeiramente para a linguagem ​Eiffel​, a metodologia de projeto por contrato
surge como uma forma eficaz para a área de desenvolvimento de sistemas pois ao longo dos
anos, uma das principais metas daqueles que estão inseridos nesta área é justamente sanar a
carência de sistemas confiáveis. O fato dela se valer de contratos humanos como base, a
torna de fácil compreensão. E no caso de ter JML especificamente para a linguagem Java,
alarga o leque de opções para os programadores no que se refere ao fato de almejar ​softwares
robustos e protegidos . Assim, entende-se que tanto o JML e ​projeto por contrato ​tenta tornar
a vida do usuário final mais cômoda, interativa e acessível quanto tenta tornar a vida do
desenvolvedor mais produtiva e do sistema mais confiável.

Palavras-chave:​ ​projeto por contrato​, Java modeling Language, Contratos.

Abstract: Man-machine interaction increasingly generates the yearning for reliable and
accessible systems. Therefore, we know that protecting information is an inherent desire of
any human being. Through this, it is worth emphasizing that spending time and money will be
excessive so that the desired goal is achieved. The purpose of this project is to demonstrate in
a practical way through the development of classes, the use of the Java Modeling Language
(JML) language, where JML works with contracts and uses the contract-by-contract theory
(Design by contract) to generate statements that aims to make systems more reliable.

¹Mestranda em Tecnologia Informática pela ​Universidad Abierta Interamericana - UAI - Buenos aires -
Argentina. decassiah@gmail.com
Developed primarily for the Eiffel language, contract-based design methodology emerges as
an effective way for systems development since, over the years, one of the main goals of those
in this area is precisely to remedy the lack of reliable systems. The fact that it uses human
contracts as a basis makes it easy to understand. And in the case of having JML specifically
for the Java language, it widens the range of options for programmers with regard to crafting
robust and protected software. Thus, it is understood that both JML and contract-based
design tries to make the end-user life more comfortable, interactive, and accessible as it tries
to make the developer's life more productive and system more reliable.

Key-words:​ Design by Contract, Java modeling Language, contracts

INTRODUÇÃO

Segundo o dicionário Houassis, ​software consiste em um conjunto de componentes lógicos de

um computador ou sistema de processamento de dados; programa, rotina ou conjunto de
instruções que controlam o funcionamento de um computador; suporte lógico. Partindo dessa
premissa entendemos que o uso do computador torna-se inviável sem o software. Sendo
assim, o extenso uso de artefatos de software nos coloca diante de questões como, a qualidade
e a confiabilidade destes artefatos, o que influencia direta ou indiretamente a vida dos
usuários.

Pensando nisso, este projeto tem como intuito de apresentar temas que abordará o uso de
tecnologias que ajudarão de forma considerável na melhoria da confiabilidade e qualidade do
software. Serão usadas as técnicas de Design by contract (DBC) ou Projeto por Contrato, em
português, que tem como idéia principal fazer com que as classes e seus clientes tenham um
contrato entre si. (NETO, 2007). A ideia central por trás das técnicas DBC está intimamente
ligada às necessidades de se desenvolver aplicações seguras e que atendam às exigências do
usuário. Assim, os contratos que são a base central dessa teoria que define prés e
pós-condições onde podem ser chamadas de benefícios mútuos, bem como invariantes que
são as restrições. Tal técnica visa uma construção de sistemas mais confiáveis, reduzindo
assim, importunos como, bugs e software mal implementado. Será apresentada a linguagem
JML (​Java Modeling Language)​, pois é uma linguagem de especificação comportamental de
tipos (classes e interfaces), que tem como intuito facilitar a vida de programadores em Java.
Ela combina a praticidade da linguagem Projeto por Contrato ​Eiffel ​(MEYER, 1992) com a
robustez do Java. Seu foco são as pré e pós-condições para os métodos e as invariantes para
as classes.

PROJETO POR CONTRATO

O que se espera de um programa computacional? Quais os meios para torná lo robusto,

confiável e correto? Teoricamente um sistema é dito correto caso ele desempenhe todas as
funções conforme sua especificação estabelece e robusto quando este lida com situações
inesperadas (não especificadas) de uma maneira tal a não comprometer todo seu
funcionamento. (JUNIOR, GUERREIRO E FIGUEIREDO, 2007, p.1456)

O precursor da teoria de Design by Contract (Projeto por Contrato) afirma que um sistema de
software é visto como um conjunto que comunica componentes cuja interação é baseada em
especificações bem definidas e obrigações mútuas - os contratos, assim, são uma espécie de
elementos que cooperam entre si.

O conceito chave de ​Design by Contract ​é ver a relação entre uma classe e

seus clientes como um acordo formal, expressando os direitos de cada
partido e obrigações. Somente através de tal definição precisa se reivindicar
de cada módulo as suas responsabilidades que podemos esperar atingir um
significativo grau de confiança em grandes sistemas de ​software​. (MEYER,
1997, p. 331)

A metodologia de projeto por contrato, a priori desenvolvida para satisfazer as necessidades

da linguagem ​Eiffel​, tem como principal objetivo e foco o desenvolvimento de sistemas
confiáveis. Esta vem de encontro às necessidades observadas ao longo do processo de
desenvolvimento do software. Contudo, independentemente da sua origem, DBC é uma
técnica de projeto valiosa para todas as linguagens de programação, incluindo Java. O DBC é
mais do que assertivas em seu código colocado em locais estratégicos. Ele visa identificar o
contrato pelo qual o seu código será executado e espera que todos os clientes venham a
aderi-lo. Trata-se, de forma clara, como uma definição de responsabilidades entre o ​software
cliente e ​software fornecedor, e assim, prover mecanismos de checagem de correção de um
sistema.

O princípio por trás de DBC é que uma classe e o seu cliente têm um contrato um com o
outro. Os contratos definem obrigações e benefícios mútuos (pré-condições e pós-condições,
respectivamente), além de restrições (invariante). Os contratos são definidos no código do
programa através de comentários da própria linguagem de programação e são traduzidos em
código executável pelo compilador. As propriedades (​predicados) do contrato são conhecidas
como asserções​ (assertions).​ (NETO, 2007,p.38).

O uso de pré e pós-condições no desenvolvimento de software não é recente, tais conceitos

foram originalmente introduzidos por Hoare e Dijkstra no final da década de 60. Porém da
forma como esses conceitos são abordados em DBC faz-se o uso de tais asserções, sendo as
pré-condições e pós-condições que definem respectivamente os direitos e as obrigações
individuais de cada método. Invariantes de classes constituem outro tipo de asserção, que
como o próprio nome denota, são propriedades que sempre são válidas ao longo do ciclo de
um objeto, asserções são representações de estados, são expressões verdadeiras em
determinados pontos de um código. E são importantes, pois são elas que tornam as correções
do programa confiáveis.

Segundo Plácido Neto, para provar que um programa ou um trecho de código

está correto, é necessário definir expressões lógicas que representam estados
desejados. Se um dos estados não for satisfeito, algo de errado ocorreu, seja
com a assertiva definida ou com a própria definição do programa. (NETO,
Plácido, 2007, p.38)

Ao longo dos anos pesquisadores foram implementando a teoria de projeto por contrato de
forma que novas técnicas de verificação de software confrontam os contratos com o código
do programa. Assim, é válido afirmar que o projeto por contrato e suas definições se
praticadas corretamente, ajudarão a melhorar consideravelmente no desenvolvimento de
aplicações que se tornarão mais confiáveis. Além do que, projeto por contrato torna a
documentação do software mais fácil uma vez que os contratos são estabelecidos. De acordo
com Júnior, Figueiredo e Guerreiro (JUNIOR; GUERREIRO; FIGUEIREDO, 2007, p.1457),
todos afirmam que isto se deve ao fato dos contratos serem mais abstratos do que o código, já
que estes não estabelecem nenhum algoritmo, se concentrando, portanto em expressar o que é
assumido e o que deve ser alcançado sem se preocupar em como isto deve ser feito. Assim, o
papel desempenhado pelos contratos através da documentação de software, ajuda a
compreender o funcionamento do código pela leitura dos contratos em vez da leitura do
código. O contrato serve, então, como documentação formal, sem ambiguidade, do que o
código faz. projeto por contrato torna-se uma forma de documentar ​software ​de maneira mais
elegante do que se basear apenas no entendimento do código ou dos comentários feitos no
programa. Graças a essa característica é possível construir uma série de ferramentas
automatizadas de suporte, fazendo com que essa documentação possa ser mantida e atualizada
sempre.

Uma vantagem de se utilizar projeto por contrato é o fato dessa técnica facilitar a depuração
do código. Com o uso dessa técnica, fica fácil localizar a causa de um possível mau
funcionamento do software. Caso a violação de um contrato for na pré-condição de um
determinado método, fica claro que o problema está localizado no código que o invocou.
Porém , se a violação se localiza na pós-condição de um método, fica claro que o problema
está na implementação deste método que não conseguiu garantir o contrato durante sua
execução. (JÚNIOR, 2006, p.18)

Para exemplificar o que foi falado, na tabela a seguir, nos valeremos de um exemplo de
contratos humanos para melhor definir projeto por contrato. Meyer (MEYER,1997, p.342)
afirma que talvez a característica mais distintiva dos contratos em que elas ocorrem nos
assuntos humanos é que qualquer bom contrato implica obrigações, bem como benefícios
para ambas as partes - a obrigação de um geralmente se transformando em um benefício para
o outro. Isto também é verdade no caso de contratos entre as classes. Veja a figura a seguir:

Figura 1.Definição de DBC através de contratos humanos.

 ● A condição prévia vincula o cliente: ela define as condições em que uma
chamada para a rotina é legítimo. É uma obrigação para o cliente e um benefício
para o fornecedor. (MEYER,1997, p.342)

● A pós-condição vincula a classe: ela define as condições que devem ser

assegurados pela rotina no retorno. É um benefício para o cliente e uma obrigação
para o fornecedor. (MEYER,1997, p.342)

JAVA MODELING LANGUAGE – JML

JML ​(Java Modeling Language) é uma linguagem de especificação de interfaces e

comportamentos ​(BISL, Behavioral Interface Specification Language) ​desenvolvida para a
especificação de módulos de programas Java (classes, interfaces e métodos) (NETO,
2007,p.17). Como podemos perceber a JML foi desenvolvida sob medida para Java. Com ela
podemos elaborar afirmações seguras, garantindo que haja uma verificação e correção da
implementação através das especificações de contrato. Isso acontece devido a JML usar as
pré-condições, pós-condições para expressar como deve ocorrer durante a inicialização e
finalização dos métodos, bem como, as invariantes para as especificações das classes. A JML
é baseada na teoria de Projeto por Contrato (​Design by Contract), assim como a linguagem
Eiffel​, e trata de uma especificação comportamental de aplicativos escritos com a linguagem
Java,(​VERZULLI, 2003​) ela foi desenvolvida por Gary Leavens, estudantes e pesquisadores da
Universidade de Iowa ​e hoje conta com alguns grupos de pesquisa que têm construído
ferramentas que dão suporte à notação JML.

Esta linguagem foi projetada para ser usada em conjunto com uma variedade de ferramentas.
Essas por sua vez, suportam projeto por contrato, checagem em tempo de execução,
descoberta de invariante, verificação estática e verificação formal, que usa provadores de
teoremas.(NETO, 2007,p.17). Além disso, JML incorpora várias características e conceitos da
abordagem de especificações orientadas a modelo ​(model-oriented) como: ​Z e Larch​. Por fim
JML provê também algumas idéias do cálculo de refinamentos (JÚNIOR, 2006). Segundo
Cheon e Leavens (CHEON; LEAVENS, 2006, p.2) projeto por contrato é melhor do que
apenas para a documentação de código; e é ainda melhor do que usar documentação informal,
como comentários de programa ou comentários​ Javadoc​.
Uma especificação de contrato é mais abstrata que o código, em parte porque ele não tem que
detalhar um algoritmo, mas pode concentrar-se no que é assumido e que deve ser alcançado.
Ao contrário de comentários, uma especificação formal em JML é reconhecida pela máquina,
verifique se for capaz, e isso pode ajudar na depuração. Isto é, a verificação da especificação
pode ajudar a isolar erros antes que eles se propaguem. Além disso, como uma especificação
de JML é verificado mecanicamente, ela tem uma chance muito maior de ser mantido até à
data com respeito ao código de documentação informal.

As cláusulas de um contrato são chamadas de asserções, através delas os benefícios e as

obrigações são definidas.O foco central de uma especificação JML são a pré-condição e a
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 à JML. (CHEON, 2003)

A linguagem JML introduz um número de construtores para descrever o comportamento.

Estes incluem ​model, fields​, quantificadores, visibilidade de escopo para as asserções,
pré-condições, pós-condições, invariantes, herança de contrato e especificações de
comportamento normal versus comportamento excepcional ​(TAYLOR, 2008, p.3)​.

ANOTAÇÕES JML E JAVA ANNOTATION 5

Na versão cinco, a linguagem Java contém construções chamadas anotações que fornecem
meta dados. A linguagem de afirmação JML geralmente, nos métodos que são especificados
por ela, tem as cláusulas que são conhecidas como ​“@Requires ​e ​“@Ensures”​. Tais
cláusulas exigem que devem ser verdadeiros antes da entrada do método. A cláusula
determina que a execução do método irá declarar se os pré-requisitos necessários são
verdadeiros.(TAYLOR, 2008)

Java ​Specification ​Request (JSR) 175 originalmente introduzido anotações em Java 5, para
tratar a crescente tendência que tem como intuito anotar campos, métodos e classes como
tendo atributos particulares que indicam que eles devem ser processados de forma especial
por ferramentas de desenvolvimento, ferramentas de implantação, ou em tempo de execução
(SUN, 2004). Projetos ​open ​source​, como o ​Apache ​Tapestry5 e ​Hibernate​, usam essas
anotações como uma alternativa para arquivos de configuração baseados em
XML(​eXtensible Markup Language)​, assim, simplifica a configuração de um arquivos
Java simples, ao invés de tanto ter um arquivo Java e um arquivo XML. Observe a forma de
as afirmações JML. Eles devem aparecer tanto em "/*" comentários e em ​"@" delimitadores
para assegurar o processamento em JML.(​TAYLOR, 2008)​. O exemplo a seguir mostra duas
formas de se escrever anotações JML.

Figura 2. Anotações em JML

FERRAMENTAS JML

As ferramentas de verificação JML podem ser classificadas em duas categorias:

• Verificação em tempo de execução

– Verificações de assertivas em tempo de execução: Envolve o teste de

especificações durante a execução de um programa. Qualquer violação de uma
especificação é relatada por meio de mensagens de erro.

• Verificação estática

– Análise estática de programas. É a análise de artefatos de software sem que haja a

execução do mesmo. No caso de JML, a análise é realizada pela ferramenta
ESC/Java2​ a partir do código fonte Java com anotações JML.

Cheon (CHEON, 2003), definiu o verificador ​runtime​(execução em tempo real) para JML.
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. Para a verificação em tempo real o compilador ​JMLC​(​Java Modeling Language
Compiler) ​ou ​compilador JML​, ​feito sob medida para JML consegue suprir as expectativas
desejadas.Já a verificação estática é feita antes da execução do programa. O adjetivo estático
enfatiza que a verificação ocorre através de uma análise estática do código. Uma importante
ferramenta de verificação estática para JML é o ​ESC/Java. ​( LAVENS, CHEON, 2006).
Exemplo de verificação em tempo de Execução com ​JMLC​. Veja a figura abaixo:

Figura 3. Compilador JML

Para uma linguagem de especificação, da mesma forma que para uma linguagem de
programação. (FREITAS; CORNELIO, 2011)

• Jml ​- realiza checagem de sintaxe e checagem de tipos de arquivos Java e JML;

• Jmlc​- compila arquivos Java (e arquivos de especificação JML) anotados com contratos
JML;

• Jmlspecs - gera um arquivo com um esqueleto para preenchimento das especificações

relativas a atributos, métodos e construtores da classe;

• Jmldoc - gera arquivos HTML (similares ao ​JavaDoc​) a partir de arquivos Java

anotados com contratos JML e arquivos JML;
 • Jmlunit - a partir de um arquivo Java anotado com contratos JML, gera código para
uma classe de testes, que pode ser utilizada para testar a classe de entrada com Junit.

• ESC/Java - a ferramenta ​ESC/Java faz verificação estática a partir da especificação, e

foi desenvolvida pela ​Compaq Systems Research Center. A ferramenta pode checar
assertivas simples e pode checar alguns tipos de erros comuns no código Java, como
referência nula ou índices de​ arrays f​ora do limite.

• OpenJML​ – Será explicada no módulo de desenvolvimento do projeto.

JML e DBC NA PRÁTICA

O alvo deste projeto é desenvolver classes que implementem DBC e JML de maneira que as
ferramentas utilizadas sejam tão eficazes na prática como na teoria. Sendo assim, podemos
considerar que o ambiente foi favorável para a análise de dados como também para que
testá-los de forma que o resultado foi consistente e proveitoso. A seguir temos relatos
inerentes ao processo de desenvolvimento dessas classes.

● OpenJML é um conjunto de ferramentas para JML, construído sobre a estrutura

OpenJDK para Java. OpenJML atua com a versão do Java 1.7 e é um trabalho em
progresso. Devido o OpenJML ​operar em arquivos Java é viável que ele seja
integrado em um ambiente de desenvolvimento Java. Portanto, seus desenvolvedores
disponibilizam um ​plug-in convencional que encapsula a ferramenta de linha de
comando no Eclipse (OPENJML, 2015).
Para que funcione é necessário ter:

● Eclipse 3.6​ ou posterior

● Um ​Java JRE 1.7

● O ​plug-in ​é instalado de forma convencional no Eclipse:

● Abra o “​Install New Software”​ na aba “​Help”​ do Eclipse

 ● Adicione um novo local, com a opção ​“Add​”, passando a URL e um nome
de sua escolha, por exemplo​: JML;

● Selecione “JML“ e clique em​ ​NEXT.

● Ao terminar clique em ​“Restart” para reiniciar o Eclipse. Se o plug-in

tiver sido instalado sem erros aparecerá na barra de menus ícones JML
como na figura a seguir:

Figura 4. ​Plugins​ JML instalados na ​IDE​ Eclipse

• Modern Jass

A sintaxe JML usado neste documento difere da sintaxe JML padrão, que é normalmente
usado como comentários. Algum projeto de linguagens de contrato, como ​Contract4J ​e
Modern Jass​, usa as anotações introduzidas no código Java 5​, que ligam metadados textuais
para construções de código. O idealizador do ​Modern Jass ​já trabalhou para chegar a um
conjunto comum de anotações Java cinco que use ​Modern Jass​ e JML. ​(TAYLOR, 2008)

A maneira mais fácil e eficiente de inserir afirmação para classes de páginas JML é usando o
Modern Jass​, uma vez que ele permite que as anotações sejam inseridas nas classes enquanto
se escreve em sintaxe Java normalmente.

Figura 5. Biblioteca​ Moder Jass

A classe ​CelulaBean. java é a representação fiel da tabela célula criada no banco de dados.
Ela será utilizada como :

Figura 6. ​CélulaBean.java​ responsável pelo mapeamento e anotações à classe.

A Classe CelulaBean.java mostra as anotações JML que ​@Require​s e ​@Ensures que afirmam
que antes de haver a execução dos métodos os valores não devem ser nulos e após a execução
o valor da variável é igual para o mesmo valor, porém, no método ​setQntidadedeMembros
devido o valor da variável ser um inteiro a afirmação exige que o valor deve ser ​>​=3 (maior
ou igual), e deve ser != 0 ​(diferente de zero). Todos os métodos dessa classe receberam
anotações JML que especifica que comportamento eles devem ter.

As anotações ​@pure sobre os métodos getters implica que 1ele só retorna o valor solicitado e
não tem efeitos colaterais ​(TAYLOR, 2008)​. JML pode verificar a pureza e alertar o
programador se o método é realmente puro ou não. Isto impede efeitos secundários
indesejados, tais como a gravação de um banco de dados durante uma chamada para um
método​ getter ​em vez de esperar até que o programa verificou todos os valores.

Figura 7: ​CélulaRN.java ​que implementa as regras de negócio.

Figura 8: ​DaoGenérico.java.
Como toda linguagem de anotação, o JML importa os pacotes necessários para que as
anotações inerentes da linguagem possam ser reconhecidas. Ao compilar a classe java anotada
com JML o ​bytecode será gerado e com suas devidas especificações que foram anotadas nas
classes.

Figura 9 : Mostra as importações do JML no​ CélulaBean.java.

A classe CelulaBean.java que é anotada com JML e ao ser executada gera um bytecode ​que
faz com que as asserções sejam válidas. Como as classes seguem o padrão MVC (​Model,
View, Controller) , a forma de o usuário saber que tais limitações existem é colocando na
classe CelulaRN.java mensagens que lhes serão expostas:
 Figura 10: Método Salvar da classe​ CelulaRN.java.

Figura 11: Tela de cadastro com validação que impede o usuário inserir um registro nulo.

.
Sendo assim, o formulário saberá que o nome não poderá receber valores em branco. Assim,
acontecerá com todos os outros campos do formulário. Segundo Kristina Taylor ​(TAYLOR,
2008), a ferramenta Rac usada no JML ainda não tem a capacidade de escrever o seu código
de verificação de erros em ​Web formulários HTML (​HyperText Markup Language)​, ​que
significa Linguagem de Marcação de hipertexto​. No entanto, alguns ​frameworks web​, como o
Apache Tapestry ​e o JFS​(​JavaServer Faces)​, utilizada neste trabalho, usam classes Java puro
para lógica formal dentro de um formulário HTML.

CONSIDERAÇÕES FINAIS

Devido a uma grande necessidade de manter as informações protegidas podemos afirmar que
a metodologia de projeto por contrato é uma ótima alternativa para quem procura tal
confiabilidade. Desde sua criação na década de 60, sua evolução foi constante. O que antes
era apenas usada pela linguagem Eiffel ​se estendeu à diversas linguagens como o Java que
tem na linguagem JML sua principal representante. Porém, a linguagem JML que faz uso dos
conceitos projeto por contrato ainda tem seus limites. Suas ferramentas ainda deixam a
desejar e a implementação que usa suas anotações, através de IDES começou a dar seu
primeiro salto. E mesmo assim, apenas a IDE ​Eclipse é favorecido com os ​plug-ins fornecidos
pelos desenvolvedores da linguagem. Contudo, a sua abordagem é ampla, e através de
pesquisas realizadas e por se tratar de uma tecnologia ​open source​, várias pessoas em todo
mundo estão em busca de um melhor aprimoramento da linguagem. Espera-se que em pouco
tempo tal linguagem venha ser mais conhecida e também mais utilizada por desenvolvedores.

Assim, através dessa abordagem podemos concluir que projeto por contrato através do JML
apesar de suas limitações é uma ótima maneira de desenvolver sistemas confiáveis e através
das vastas pesquisas desenvolvidas em todo o mundo, em pouco tempo nos valeremos de uma
linguagem mais robusta no que se refere às especificações das classes.Para trabalhos futuros,
fica uma sugestão de explorar os conceito e a integração do DBC com em outras linguagens
que tem crescido no mercado como​ python​ e saber se é tão eficaz como foi para o Java.

REFERENCIAIS BIBLIOGRÁFICOS

JUNIOR, Rogério Dourado Silva ,FIGUEIREDO Jorge Cesar Abrantes de, GUERREIRO
Dalton Serey - Design by Contract com JML. 2007, XXVI Congresso da Sociedade
Brasileira de Computação - São Leopoldo/RS

MEYER, BETRAND. ​Object-Oriented Software Construction​. Prentice Hall, 2 edition,

New York, NY: 1997
MEYER, BETRAND. Eiffel: ​The Language. Object Oriented Series. Prentice Hall, New
York, NY, 1992.

NETO, Placido de Souza - JCML - ​Java Card Modeling Language: Definição e

Implementação ​Natal/RN, 2007

JÚNIOR , Frederico Guilherme Alvares de Oliveira - ​CML: Uma Linguagem ​especificação

de Requisitos Funcionais para C.​ 2006

LEAVENS Gary. T.,CHEON Yoonsik. ​Design by contract with JML​. Draft, available from
jmlspecs.org​ , 2006.
CHEON, Y. A ​Runtime Assertion Checker for the Java Modeling Language. Ph.D.
thesis. Department of Computer Science, Iowa State University, April 2003.

VERZULLI, Joe. ​Getting started with JML: Improve your Java programs with JML
annotation.​ IBM DeveloperWorks article, 2003.

TAYLOR, Kristina Boysen - ​A specification language Projeto for the Java Modeling
Language (JML) using Java 5 annotations - ​Iowa/2008

SUN MICROSYSTEMS, INC. JSR 175: ​A metadata facility for the Java programming
language​. ​http://jcp.org/en/jsr/detail?id=175​ (Acesso 06 de março , 2018), 2004.

FREITAS, Gabriel Falconieri , CORNÉLIO Márcio - ​– Artigo: ​Design by Contract e Java

- ​Revista Java Magazine Ed. 88 , ano VII - ​2011 ​– Disponível em
http://www.devmedia.com.br/post-19275-Projeto-by-Contract-e-Java.html

OPENJML - ​http://www.openjml.org/​, 2015 - Acesso, 03 de março 2018