Made available in DSpace on 2014-12-17T15:47:43Z (GMT). No. of bitstreams: 1 PlacidoASN.pdf: 652214 bytes, checksum: b7912104bf8e3ec91262c75b9ef5d36b (MD5) Previous issue date: 2007-09-06 / Coordena??o de Aperfei?oamento de Pessoal de N?vel Superior / Formal methods should be used to specify and verify on-card software in Java Card applications. Furthermore, Java Card programming style requires runtime verification of all input conditions for all on-card methods, where the main goal is to preserve the data in the card. Design by contract, and in particular, the JML language, are an option for this kind of development and verification, as runtime verification is part of the Design by contract method implemented by JML. However, JML and its currently available tools for runtime verification were not designed with Java Card limitations in mind and are not Java Card compliant. In this thesis, we analyze how much of this situation is really intrinsic of Java Card limitations and how much is just a matter of a complete re-design of JML and its tools. We propose the requirements for a new language which is Java Card compliant and indicate the lines on which a compiler for this language should be built. JCML strips from JML non-Java Card aspects such as concurrency and unsupported types. This would not be enough, however, without a great effort in optimization of the verification code generated by its compiler, as this verification code must run on the card. The JCML compiler, although being much more restricted than the one for JML, is able to generate Java Card compliant verification code for some lightweight specifications. As conclusion, we present a Java Card compliant variant of JML, JCML (Java Card Modeling Language), with a preliminary version of its compiler / M?todos formais poderiam ser usados para especificar e verificar software on-card em aplica??es Java Card. O estilo de programa??o para smart cards requer verifica??o em tempo de execu??o para condi??es de entrada em todos os m?todos Java Card, onde o objetivo principal ? preservar os dados do cart?o. Projeto por Contrato, em particular, a linguagem JML, ? uma op??o para este tipo de desenvolvimento e verifica??o, pelo fato da verifica??o em tempo de execu??o ser parte da implementa??o pela JML. Contudo, JML e suas respectivas ferramentas para verifica??o em tempo de execu??o n?o foram projetadas com o foco nas limita??es Java Card, sendo, dessa forma, n?o compat?veis com Java Card. Nesta disserta??o, analisamos o quanto esta situa??o ? realmente intr?nseca ?s limita??es Java Card e, se ? poss?vel re-definir a JML e suas ferramentas. Propomos requisitos para uma nova linguagem, a qual ? compat?vel com Java Card e apresentamos como o compilador desta linguagem pode ser constru?do. JCML retira da JML aspectos n?o definidos em Java Card, como por exemplo, concorr?ncia e tipos n?o suportados. Isto pode n?o ser o bastante, contudo, sem o esfor?o em otimiza??o de c?digo de verifica??o gerado pelo compilador, n?o ? poss?vel gerar c?digo de verifica??o para rodar no cart?o. O compilador JCML, apesar de ser bem mais restrito em rela??o ao compilador JML, est? habilitado a gerar c?digo de verifica??o compat?vel com Java Card, para algumas especifica??es lightweight. Como conclus?o, apresentamos uma variante da JML compat?vel com Java Card, JCML (Java Card Modeling Language), com uma vers?o de seu compilador

Submitted by Nayara Passos (nayara.passos@ufpe.br) on 2015-03-12T12:46:58Z No. of bitstreams: 2 TESE Henrique Emanuel Rabêlo.pdf: 2393775 bytes, checksum: b74f8b8b1b46d5879b334348c3110846 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) / Approved for entry into archive by Daniella Sodre (daniella.sodre@ufpe.br) on 2015-03-13T12:53:22Z (GMT) No. of bitstreams: 2 TESE Henrique Emanuel Rabêlo.pdf: 2393775 bytes, checksum: b74f8b8b1b46d5879b334348c3110846 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) / Made available in DSpace on 2015-03-13T12:53:22Z (GMT). No. of bitstreams: 2 TESE Henrique Emanuel Rabêlo.pdf: 2393775 bytes, checksum: b74f8b8b1b46d5879b334348c3110846 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Previous issue date: 2014 / Design by Contract (DbC) ´e uma t´ecnica popular para desenvolvimento de programas usando especifica¸c˜oes comportamentais. Neste contexto, pesquisadores descobriram que a implementao de DbC ´e crosscutting e, portanto, sua implementa¸c˜ao ´e melhor modularizada por meio da Programa¸c˜ao Orientada a Aspectos (POA) por´em, os mecanismos de POA para dar suporte a modularide de contratos, de fato comprometem sua modularidade e entendidmento. Por exemplo, na linguagem POA AspectJ, o racioc´ınio da corretude de uma chamada de m´etodo requer uma an´alise global do programa para determinar quais advice aplicam e sobretudo o que esses advice fazem em rela¸c˜ao a implementa ¸c˜ao e checagem DbC. Al´em disso, quando os contratos so separados das classes o programador corre o risco de quebrar-los inadvertidamente. Diferentemente de uma linguagem POA como AspectJ, uma linguagem DbC preserva as principais caractersticas DbC como raciocnio modular e documenta¸c˜ao. No entanto, pr´e- e p´os-condi¸c˜oes recorrentes continuam espalhadas por todo o sistema. Infelizmente esse n˜ao o ´unico problema relacionado com modularidade que temos em linguagens DbC existentes, o seu com respectivos verificadores dinˆamicos so inconsistentes com as regras de information hiding devido a naturaze overly-dynamic na qual os contratos s˜ao checados no lado servidor. Este problema implica que durante a reportagem de erros, detalhes de implementa¸c˜ao so expostos para clientes no privilegiados. Portanto, se os programadores cuidadosamente escolherem as partes que devem ser escondidas dos clientes, durante a checagem dinˆamica de contratos, as mudanas nessas partes n˜ao deveriam afetar nem os clientes dos m´odulos nem a reportagem de erros de contratos. Neste trabalho n´os resolvemos esses problemas com AspectJML, uma nova liguagem de especifica¸c˜ao que suporta contratos crosscutting para c´odigo Java. Al´em disso, n´os demonstramos como AspectJML usa as principais caractersticas de uma linguagem DbC como racioc´ınio modular e documenta¸c˜ao dos contratos. Mais ainda, n´os mostramos como AspectJML combinado com nossa t´ecnica chamada de client-aware checking permite uma checagem dinˆamica de contratos que respeitem os princ´ıpios de information hiding em especifica¸c˜oes. Neste trabalho usamos JML para fins concretos, mas nossa solu¸c˜ao pode ser utilizadas para outras linguagems Java-likee suas respectivas linguagens DbC. Para concluir, n´os conduzimos uma avalia¸c˜ao da nossa modulariza¸c˜ao dos contratos crosscutting usando AspectJML, onde observamos que seu uso reduz o esforo de escrever pr´e- e p´os-condies, por´em com um pequeno overhead em tempo de compila¸c˜ao e instrumentação de código para checagem de contratos. / Design by Contract (DbC) is a popular technique for developing programs using behavioral specifications. In this context, researchers have found that the realization of DbC is crosscutting and fares better when modularized by Aspect-Oriented Programming. However, previous efforts aimed at supporting crosscutting contracts modularly actually compromised the main DbC principles. For example, in AspectJ-style, reasoning about the correctness of a method call may require a whole-program analysis to determine which advice applies and what that advice does relative to DbC implementation and checking. Also, when contracts are separated from classes a programmer may not know about them and may break them inadvertently. Unlike an AspectJ-like language, a DbC language keeps the main DbC principles such as modular reasoning and documentation. However, a recurrent pre- or postcondition specification remains scattered across several methods in many types. Unfortunately, this is not the only modularity problem we have with existing DbC languages. Such languages along with their respective runtime assertion checkers are inconsistent with information hiding rules because they check specifications in an overly-dynamic manner on the supplier side. This implies that during error reporting, hidden implementation details are exposed to non-privileged clients. Such details should not be used in a client’s correctness proof, since otherwise the proof would be invalidated when they change. Therefore, if programmers have carefully chosen to hide those parts “most likely” to change, most changes, in the hidden implementation details, do not affect either module clients nor DbC error reporting. In this work we solve these problems with AspectJML, a new specification language that supports crosscutting contracts for Java code. We also show how AspectJML supports the main DbC principles of modular reasoning and contracts as documentation. Additionally, we explain how AspectJML combined with our client-aware checking technique allows runtime checking to use the privacy information in specifications, which promotes information hiding. We use JML for concreteness, but the solution we propose can also be used for other Java-like languages and their respective DbC languages. To conclude, we conduct an evaluation to assess the crosscutting contract modularization using AspectJML, where we observe that its use reduces the overall design by contract code, including pre- and postconditions, but introduces a small overhead during compile time and can increase the resulting bytecode due to code instrumentation to check ordinary and crosscutting contracts

To reason about a program means to state or conclude, by logical means, some properties the program exhibits; like its correctness according to certain expected behavior. The continuous need for more ambitious, more complex, and more dependable software systems demands for better mechanisms to modularize them and reason about their correctness. The reasoning process is affected by the design decisions made by the developer of the program and by the features supported by the programming language used. Beyond Object Orientation, Implicit Invocation and Aspect Oriented languages pose very hard reasoning challenges. Important tradeoffs must be considered while reasoning about a program: modular vs. non-modular reasoning, case-by-case analysis vs. abstraction, explicitness vs. implicitness; are some of them. By deciding a series of tradeoffs one can configure a reasoning scenario. For example if one decides for modular reasoning and explicit invocation a well-known object oriented reasoning scenario can be used. This dissertation identifies various important tradeoffs faced when reasoning about implicit invocation and aspect oriented programs, characterize scenarios derived from making choices regarding these tradeoffs, and provides sound proof rules for verification of programs covered by all these scenarios. Guidance for program developers and language designers is also given, so that reasoning about these types of programs becomes more tractable.

The Java platform is becoming a vital tool for developing real-time and safety-critical systems. Design patterns and the availability of Java libraries, both provide solutions to many known problems. Furthermore, the object-oriented nature of Java simplifies modular development of real-time systems. However, limitations of Java as a programming language for real-time systems are a notable obstacle to producing safe real-time systems. These limitations are found in the unpredictable execution model of the language, due to Java’s garbage collector, and the lack of support for non-functional specification and verification tools. In this dissertation I introduce SafeJML, a specification language for support of functional and non-functional specifications, based on an implementation of a safety-critical Java platform and the Java Modeling Language (JML). This dissertation concentrates on techniques that enable specification and dynamic checking of timing constraints for some important Java features, including methods and subtyping. SafeJML and these dynamic checking techniques allow modular specification and checking of safety-critical systems, including those that use object-orientation and design patterns. Such coding techniques could have maintenance benefits for real-time and safety-critical software

This thesis presents a tool for SPEcification based teSTing (SPEST). SPEST is designed to use well known practices for automated black-box testing to reduce the burden of testing on developers. The tool uses a simple formal specification language to generate highly-readable unit tests that embody best practices for thorough software testing. Because the specification language used to generate the assertions about the code can be compiled, it can also be used to ensure that documentation describing the code is maintained during development and refactoring. The utility and effectiveness of SPEST were validated through several exper- iments conducted with students in undergraduate software engineering classes. The first experiment compared the understandability and efficiency of SPEST generated tests against student written tests based on the Java Modeling Lan- guage (JML)[25] specifications. JML is a widely used language for behavior program specification. A second experiment evaluated readability through a sur- vey comparing SPEST generated tests against tests written by well established software developers. The results from the experiments showed that SPEST’s specification language is at least understandable as JML, SPEST’s specification language is more readable than JML, and strongly suggest that SPEST is capable of reducing the effort required to produce effective tests.

Made available in DSpace on 2014-12-17T15:48:07Z (GMT). No. of bitstreams: 1 AntonioAOVS.pdf: 849695 bytes, checksum: 575cdb368ae14f3aad606763ebea7114 (MD5) Previous issue date: 2004-10-13 / The widespread growth in the use of smart cards (by banks, transport services, and cell phones, etc) has brought an important fact that must be addressed: the need of tools that can be used to verify such cards, so to guarantee the correctness of their software. As the vast majority of cards that are being developed nowadays use the JavaCard technology as they software layer, the use of the Java Modeling Language (JML) to specify their programs appear as a natural solution. JML is a formal language tailored to Java. It has been inspired by methodologies from Larch and Eiffel, and has been widely adopted as the de facto language when dealing with specification of any Java related program. Various tools that make use of JML have already been developed, covering a wide range of functionalities, such as run time and static checking. But the tools existent so far for static checking are not fully automated, and, those that are, do not offer an adequate level of soundness and completeness. Our objective is to contribute to a series of techniques, that can be used to accomplish a fully automated and confident verification of JavaCard applets. In this work we present the first steps to this. With the use of a software platform comprised by Krakatoa, Why and haRVey, we developed a set of techniques to reduce the size of the theory necessary to verify the specifications. Such techniques have yielded very good results, with gains of almost 100% in all tested cases, and has proved as a valuable technique to be used, not only in this, but in most real world problems related to automatic verification / O grande crescimento do uso de smart cards (por bancos, companhias de transporte, celulares, etc) trouxe um fato importante, que deve ser considerado: a necessidade de ferramentas que possam ser usadas para verificar os cart?es, para que se possa garantir a corretude de seu software. Como a grande maioria dos cart?es desenvolvidos hoje em dia usa a tecnologia JavaCard em sua camada de software, o uso da Java Modeling Language (JML) para especificar os programas aparece como uma solu?ao natural. JML ? uma linguagem de especifica??o formal ligada ao Java. Ela foi inspirada pelas metodologias de Larch e Eiffel, e foi largamente adotada como a linguagem de facto em se tratando da especifica??o de qualquer programa relacionado ? Java. V?rias ferramentas que fazem uso de JML j? foram desenvolvidas, cobrindo uma grande gama de funcionalidades, entre elas, a verifica??o em tempo de execu??o e est?tica. Mas as ferramentas existentes at? o momento para a verifica??o est?tica n?o s?o totalmente automatizadas, e, aquelas que s?o, n?o oferecem um n?vel adequado de completude e seguran?a. Nosso objetivo ? contribuir com uma s?rie de t?cnicas, que podem ser usadas para alcan?ar uma verifica??o completamente autom?tica e segura para applets JavaCard. Nesse trabalho n?s apresentamos os primeiros passos nessa dire??o. Com o uso de uma plataforma de software composta pelo Krakatoa, Why e haRVey, n?s desenvolvemos um conjunto de t?cnicas para reduzir o tamanho da teoria necess?ria para verificar as especifica??es. Tais t?cnicas deram resultados muito bons, com ganhos de quase 100% em todos os testes que realizamos, e se provou como uma t?cnica que deve ser sempre considerAda, n?o somente nesse, mas na maioria dos problemas reais relacionado com verifica??o autom?tica

Notre approche, dans le cadre du test de conformité, se base sur le fait qu'il existe différents niveaux d'abstraction pour définir des tests : les tests exécutables pour une cible technologique et les tests abstraits qui sont indépendants de la technologie. Nos travaux portent sur deux points. <br />Le premier point vise à réduire l'effort alloué à la conception des tests. Pour cela nous définissons un nouveau niveau d'abstraction : les schémas de test qui offrent une abstraction supplémentaire sur les instances et valeurs manipulées. L'outil Tobias a été développé au cours de la thèse pour aider à la conception des schémas de test, les déplier en cas de test abstraits, puis concrétiser ces cas de test. <br />Malheureusement, les principes du langage de schéma de tests entraînent un problème d'explosion combinatoire du nombre de tests. Nous proposons donc diverses approches pour, d'une part, mieux contrôler le nombre de tests produits et, d'autre part, optimiser le temps d'exécution des tests. <br />Ces diverses techniques ont pu être intégrées à l'outil Tobias, nous permettant de réaliser deux études de cas afin de valider notre approche.

Submitted by Johnny Rodrigues (johnnyrodrigues@ufcg.edu.br) on 2018-08-31T22:55:43Z No. of bitstreams: 1 CATUXE VARJÃO DE SANTANA OLIVEIRA - PPGCC DISSERTAÇÃO 2013..pdf: 11354934 bytes, checksum: 6a23f31ef43ba211aeaa89eb36061a43 (MD5) / Made available in DSpace on 2018-08-31T22:55:43Z (GMT). No. of bitstreams: 1 CATUXE VARJÃO DE SANTANA OLIVEIRA - PPGCC DISSERTAÇÃO 2013..pdf: 11354934 bytes, checksum: 6a23f31ef43ba211aeaa89eb36061a43 (MD5) Previous issue date: 2013-03-15 / A escrita de especificações formais por contratos é uma maneira confiável e prática de construir softwares, em que desenvolvedores e clientes mantêm um acordo contendo direitos e obrigações a serem cumpridos. Essas responsabilidades são expressas basicamente através de pré-condições, pós-condições, e invariantes. Como exemplo de linguagem de especificação por contrato tem-se Java Modeling Language (JML) específica para programas Java. Apesar de a especificação formal melhorar a confiabilidade do software, deve-se haver certificação de que a implementação está em conformidade com a especificação definida. Verificação de conformidade em programas com contratos é geralmente realizada através de análises manuais ou verificação dinâmica, e em fases tardias do processo de desenvolvimento do software, ou seja, quando o produto final encontra-se disponível para o cliente. Nesta situação, o tempo despendido para detectar não-conformidades pode ser muito longo, ocasionando, consequentemente, atrasos no cronograma e aumento nos custos. Neste trabalho, propomos uma abordagem para checar conformidade entre código fonte e especificação formal por contratos através da geração e execução de testes. Testes de unidade são gerados automaticamente, resultando em casos de testes com sequências de chamadas aos métodos e construtores. Os contratos são transformados em assertivas que funcionam como oráculo para os testes. Esta abordagem não garante corretude total do software, mas aumenta a confiança quando uma não-conformidade é encontrada e, além disso, encoraja o uso de especificação por contratos. Nós implementamos JMLOK, uma ferramenta que executa os passos desta abordagem automaticamente no contexto de programas Java especificados com Java Modeling Language (JML). JMLOK foi avaliada em grupos de programas Java/JML, incluindo um módulo do projeto JavaCard. Todas as unidades experimentais totalizam 18 KLOC e 5K de linhas de especificação JML. Todo o processo consumiu menos que 10 minutos de execução e gerou como resultado a detecção de 29 não-conformidades. As causas das ocorrências das não-conformidades foram analisadas manualmente e classificadas em categorias de falhas. / Writing formal specifications by contracts is a practical and reliable way to build softwares in which developers and clients keep an agreement with rights and obligations to be fulfilled. These responsibilities are expressed basically by pre-conditions, post-conditions and invariants. As example of specification language by contract there is Java Modeling Language (JML) that is specific to Java programs. Although formal specification improves software rehabihty, it should exist certification of conformance with defined specification. Verify conformance between programs and contracts is usually performed by manual analysis or dynamic verification, and in late stages of software development process, that is, when the final product is available to client. In this situation, the time required to detect nonconformances could be so long, causing, consequently, schedule delays and increased costs. In this work, we propose an approach to check conformance between source code and contract formal specification through testing generation and execution. Unit tests are generated automatically resulting in test cases with call sequences of methods and constructors. The contracts are translated in assertions that work like test oracle. We have implemented JMLOK, a tool performs the approach steps automatically in the context of Java programs specified with Java Modeling Language (JML). JMLOK was evaluated in Java/JML programs groups, including a module of the JavaCard project. All the experimental units totalize 18 KLOC and 5K lines of JML specification. All process took less than 10 minutes of running and generated as result 29 nonconformances. The causes of nonconformances occurring were analyzed manually and classified in categories of fails.