Validating transformations of OO programs using the alloy analyzer
Autor(a) principal: | |
---|---|
Data de Publicação: | 2017 |
Tipo de documento: | Tese |
Idioma: | eng |
Título da fonte: | Repositório Institucional da UFPE |
Texto Completo: | https://repositorio.ufpe.br/handle/123456789/31379 |
Resumo: | Program transformation is current practice in software development, especially refactoring. However, in general, there is no precise specification of these transformations and, when it exists, it is neither proved sound nor validated systematically, which can cause static semantic or behavioural errors in the resulting programs, after each transformation application. This work proposes a strategy to validate program transformation specifications grounded by a formal infrastructure built predominantly in Alloy. In this work we focus on transformations in languages that support OO features such as Java, ROOL, the calculus of refinement of component and object-oriented systems known as rCOS and an OO language with reference semantic. The scope of this work, concerning the strategy implementation, is a subset of Java. Complementarily to testing, formal languages provide a mathematically solid reasoning mechanism to establish the soundness of transformations. Unfortunately, a complete formal treatment for transformations in OO languages is ruled out because even for Java there is no complete formal semantics. We investigate the trustworthiness of program transformations by using an approach that combines (bounded) model finding and testing. Our Alloy formal infrastructure comprises four main Alloy models: (1) a metamodel for a subset of OO language features and a set of predicates that capture the static semantics, where the main predicate is able to determine if a program is well–formed; (2) a Transformation-Specific model for each program transformation being investigated; (3) a Static Semantics Validator model; and (4) a Dynamic Validator Model, which generates all possible instances (according to the scope specified), each one having a representation of a program before and after the transformation application. If any instances are generated in (3), this means that there is a failure in the transformation specification. So, in this case it is necessary to correct the specification and re–submit it to the Alloy Analyzer. This process is repeated until no more instances are found by the Static Semantics Validator Model. Hence, the instances generated by the Dynamic Validator model only represent well–formed programs since it is only applied after the Static Semantics Validator model. Afterwards, the instances generated by (4) are further submitted to a tool, called Alloy-To-Java Translator, which generates Java programs corresponding to these instances along with tests to be applied in each side of the transformation. These programs are finally validated with regard to dynamic semantic problems, based on these automatic tests generated in (4). In this way, a developer can implement the transformations with some confidence on their behavioural preservation, after validating the transformation specifications using the proposed framework. The strategy we propose seems promising since it is an alternative to validate transformations even when a complete semantics of the languages is not available. The results of the validation of a representative set of transformations found in the literature show that some transformation issues, concerning both static and dynamic behaviour, can be detected. |
id |
UFPE_898eaac3181a71dee2fa2ee0b3e68b31 |
---|---|
oai_identifier_str |
oai:repositorio.ufpe.br:123456789/31379 |
network_acronym_str |
UFPE |
network_name_str |
Repositório Institucional da UFPE |
repository_id_str |
2221 |
spelling |
SILVA, Tarciana Dias dahttp://lattes.cnpq.br/6930023635739057http://lattes.cnpq.br/3977760354511853SAMPAIO, Augusto Cezar AlvesMOTA, Alexandre Cabral2019-07-08T18:30:23Z2019-07-08T18:30:23Z2017-08-23https://repositorio.ufpe.br/handle/123456789/31379Program transformation is current practice in software development, especially refactoring. However, in general, there is no precise specification of these transformations and, when it exists, it is neither proved sound nor validated systematically, which can cause static semantic or behavioural errors in the resulting programs, after each transformation application. This work proposes a strategy to validate program transformation specifications grounded by a formal infrastructure built predominantly in Alloy. In this work we focus on transformations in languages that support OO features such as Java, ROOL, the calculus of refinement of component and object-oriented systems known as rCOS and an OO language with reference semantic. The scope of this work, concerning the strategy implementation, is a subset of Java. Complementarily to testing, formal languages provide a mathematically solid reasoning mechanism to establish the soundness of transformations. Unfortunately, a complete formal treatment for transformations in OO languages is ruled out because even for Java there is no complete formal semantics. We investigate the trustworthiness of program transformations by using an approach that combines (bounded) model finding and testing. Our Alloy formal infrastructure comprises four main Alloy models: (1) a metamodel for a subset of OO language features and a set of predicates that capture the static semantics, where the main predicate is able to determine if a program is well–formed; (2) a Transformation-Specific model for each program transformation being investigated; (3) a Static Semantics Validator model; and (4) a Dynamic Validator Model, which generates all possible instances (according to the scope specified), each one having a representation of a program before and after the transformation application. If any instances are generated in (3), this means that there is a failure in the transformation specification. So, in this case it is necessary to correct the specification and re–submit it to the Alloy Analyzer. This process is repeated until no more instances are found by the Static Semantics Validator Model. Hence, the instances generated by the Dynamic Validator model only represent well–formed programs since it is only applied after the Static Semantics Validator model. Afterwards, the instances generated by (4) are further submitted to a tool, called Alloy-To-Java Translator, which generates Java programs corresponding to these instances along with tests to be applied in each side of the transformation. These programs are finally validated with regard to dynamic semantic problems, based on these automatic tests generated in (4). In this way, a developer can implement the transformations with some confidence on their behavioural preservation, after validating the transformation specifications using the proposed framework. The strategy we propose seems promising since it is an alternative to validate transformations even when a complete semantics of the languages is not available. The results of the validation of a representative set of transformations found in the literature show that some transformation issues, concerning both static and dynamic behaviour, can be detected.Transformação de programas é uma prática atual em desenvolvimento de software, especialmente refactoring. No entanto, em geral, não há uma especificação precisa dessas transformações e, quando existe, não é provada correta nem sistematicamente validada, o que pode causar erros de semântica estática ou comportamentais nos programas resultantes da transformação. Este trabalho propõe uma estratégia, baseada em uma infraestrutura predominantemente formal construída em Alloy, para validar especificações de transformação de programas. Neste trabalho, focamos em transformações em linguagens que suportam características orientadas a objetos (OO) tais como Java, ROOL, o cálculo de refinamento de componentes e sistemas orientados a objetos, conhecido como rCOS e uma linguagem OO com semântica de referência. O escopo deste trabalho, com relação à implementação da estratégia, é um subconjunto de Java. Complementarmente a testes, linguagens formais fornecem um mecanismo matematicamente sólido para estabelecer a consistência (soundness) das transformaçõoes. Infelizmente, um tratamento formal completo para transformações em linguagens OO é descartado porque, mesmo para Java, não há uma semântica formal completa. Nós investigamos a corretude de transformações de programas usando uma abordagem que combina (bounded) model finding e testes. Nossa infraestrutura formal é composta de quatro modelos Alloy principais: (1) um metamodelo para um subconjunto de características de linguagens OO e um conjunto de predicados que capturam a semântica estática correspondente, onde o predicado principal é capaz de determinar se um programa é bem–formado; (2) um modelo específico para cada transformação (que está sendo investigada); (3) um Validador de Semântica Estática e (4) um Validador Dinâmico, que gera instâncias possíveis da transformação (de acordo com o escopo especificado), cada uma tendo uma representação de um programa antes e depois da transformação. Se alguma instância for gerada em (3), isto significa que há uma falha (de semântica estática) na especificação da transformação. Neste caso, é necessário corrigir a especificação e re–submetê–la para o Alloy Analyzer. Este procedimento é repetido até nenhuma instância ser encontrada pelo modelo do Validador de Semântica Estática. Logo, as instâncias geradas pelo modelo do Validador Dinâmico (4) tipicamente somente representam programas bem formados já que este é aplicado na nossa estratégia apenas depois que o modelo em (3) não retornar instância alguma. Em seguida, as instâncias geradas em (4) são submetidas a uma ferramenta, Alloy–To–Java Translator, que transforma as instâncias geradas em programas Java, e também gera os testes que serão aplicados em cada lado da transformação. Estes programas são finalmente validados com relação a problemas dinâmicos com base nestes testes gerados em (4) de forma automática. Dessa forma, um desenvolvedor pode implementar as transformações com alguma segurança depois de validar a especificação das transformações usando o framework proposto. A estratégia que propomos parece promissora já que é uma alternativa para validar especificações de transformações em geral mesmo quando uma semântica completa da linguagem não está disponível. Resultados da validação de um conjunto representativo de especificações de transformações, encontrados na literatura, mostram que tanto problemas de semântica estática quanto dinâmica podem ser detectados.engUniversidade Federal de PernambucoPrograma de Pos Graduacao em Ciencia da ComputacaoUFPEBrasilAttribution-NonCommercial-NoDerivs 3.0 Brazilhttp://creativecommons.org/licenses/by-nc-nd/3.0/br/info:eu-repo/semantics/openAccessEngenharia de softwareLinguagem de programaçãoValidating transformations of OO programs using the alloy analyzerinfo:eu-repo/semantics/publishedVersioninfo:eu-repo/semantics/doctoralThesisdoutoradoreponame:Repositório Institucional da UFPEinstname:Universidade Federal de Pernambuco (UFPE)instacron:UFPETHUMBNAILTESE Tarciana Dias da Silva.pdf.jpgTESE Tarciana Dias da Silva.pdf.jpgGenerated Thumbnailimage/jpeg1240https://repositorio.ufpe.br/bitstream/123456789/31379/5/TESE%20Tarciana%20Dias%20da%20Silva.pdf.jpgc466c733b782012a9847749b1fd81e36MD55ORIGINALTESE Tarciana Dias da Silva.pdfTESE Tarciana Dias da Silva.pdfapplication/pdf3498833https://repositorio.ufpe.br/bitstream/123456789/31379/1/TESE%20Tarciana%20Dias%20da%20Silva.pdf68f76a63110f7a6a806f639bd7e014eaMD51CC-LICENSElicense_rdflicense_rdfapplication/rdf+xml; charset=utf-8811https://repositorio.ufpe.br/bitstream/123456789/31379/2/license_rdfe39d27027a6cc9cb039ad269a5db8e34MD52LICENSElicense.txtlicense.txttext/plain; charset=utf-82310https://repositorio.ufpe.br/bitstream/123456789/31379/3/license.txtbd573a5ca8288eb7272482765f819534MD53TEXTTESE Tarciana Dias da Silva.pdf.txtTESE Tarciana Dias da Silva.pdf.txtExtracted texttext/plain320642https://repositorio.ufpe.br/bitstream/123456789/31379/4/TESE%20Tarciana%20Dias%20da%20Silva.pdf.txtfbb13ecd109e39733edd5c82c8854e51MD54123456789/313792019-10-25 10:16:37.817oai:repositorio.ufpe.br:123456789/31379TGljZW7Dp2EgZGUgRGlzdHJpYnVpw6fDo28gTsOjbyBFeGNsdXNpdmEKClRvZG8gZGVwb3NpdGFudGUgZGUgbWF0ZXJpYWwgbm8gUmVwb3NpdMOzcmlvIEluc3RpdHVjaW9uYWwgKFJJKSBkZXZlIGNvbmNlZGVyLCDDoCBVbml2ZXJzaWRhZGUgRmVkZXJhbCBkZSBQZXJuYW1idWNvIChVRlBFKSwgdW1hIExpY2Vuw6dhIGRlIERpc3RyaWJ1acOnw6NvIE7Do28gRXhjbHVzaXZhIHBhcmEgbWFudGVyIGUgdG9ybmFyIGFjZXNzw612ZWlzIG9zIHNldXMgZG9jdW1lbnRvcywgZW0gZm9ybWF0byBkaWdpdGFsLCBuZXN0ZSByZXBvc2l0w7NyaW8uCgpDb20gYSBjb25jZXNzw6NvIGRlc3RhIGxpY2Vuw6dhIG7Do28gZXhjbHVzaXZhLCBvIGRlcG9zaXRhbnRlIG1hbnTDqW0gdG9kb3Mgb3MgZGlyZWl0b3MgZGUgYXV0b3IuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKTGljZW7Dp2EgZGUgRGlzdHJpYnVpw6fDo28gTsOjbyBFeGNsdXNpdmEKCkFvIGNvbmNvcmRhciBjb20gZXN0YSBsaWNlbsOnYSBlIGFjZWl0w6EtbGEsIHZvY8OqIChhdXRvciBvdSBkZXRlbnRvciBkb3MgZGlyZWl0b3MgYXV0b3JhaXMpOgoKYSkgRGVjbGFyYSBxdWUgY29uaGVjZSBhIHBvbMOtdGljYSBkZSBjb3B5cmlnaHQgZGEgZWRpdG9yYSBkbyBzZXUgZG9jdW1lbnRvOwpiKSBEZWNsYXJhIHF1ZSBjb25oZWNlIGUgYWNlaXRhIGFzIERpcmV0cml6ZXMgcGFyYSBvIFJlcG9zaXTDs3JpbyBJbnN0aXR1Y2lvbmFsIGRhIFVGUEU7CmMpIENvbmNlZGUgw6AgVUZQRSBvIGRpcmVpdG8gbsOjbyBleGNsdXNpdm8gZGUgYXJxdWl2YXIsIHJlcHJvZHV6aXIsIGNvbnZlcnRlciAoY29tbyBkZWZpbmlkbyBhIHNlZ3VpciksIGNvbXVuaWNhciBlL291IGRpc3RyaWJ1aXIsIG5vIFJJLCBvIGRvY3VtZW50byBlbnRyZWd1ZSAoaW5jbHVpbmRvIG8gcmVzdW1vL2Fic3RyYWN0KSBlbSBmb3JtYXRvIGRpZ2l0YWwgb3UgcG9yIG91dHJvIG1laW87CmQpIERlY2xhcmEgcXVlIGF1dG9yaXphIGEgVUZQRSBhIGFycXVpdmFyIG1haXMgZGUgdW1hIGPDs3BpYSBkZXN0ZSBkb2N1bWVudG8gZSBjb252ZXJ0w6otbG8sIHNlbSBhbHRlcmFyIG8gc2V1IGNvbnRlw7pkbywgcGFyYSBxdWFscXVlciBmb3JtYXRvIGRlIGZpY2hlaXJvLCBtZWlvIG91IHN1cG9ydGUsIHBhcmEgZWZlaXRvcyBkZSBzZWd1cmFuw6dhLCBwcmVzZXJ2YcOnw6NvIChiYWNrdXApIGUgYWNlc3NvOwplKSBEZWNsYXJhIHF1ZSBvIGRvY3VtZW50byBzdWJtZXRpZG8gw6kgbyBzZXUgdHJhYmFsaG8gb3JpZ2luYWwgZSBxdWUgZGV0w6ltIG8gZGlyZWl0byBkZSBjb25jZWRlciBhIHRlcmNlaXJvcyBvcyBkaXJlaXRvcyBjb250aWRvcyBuZXN0YSBsaWNlbsOnYS4gRGVjbGFyYSB0YW1iw6ltIHF1ZSBhIGVudHJlZ2EgZG8gZG9jdW1lbnRvIG7Do28gaW5mcmluZ2Ugb3MgZGlyZWl0b3MgZGUgb3V0cmEgcGVzc29hIG91IGVudGlkYWRlOwpmKSBEZWNsYXJhIHF1ZSwgbm8gY2FzbyBkbyBkb2N1bWVudG8gc3VibWV0aWRvIGNvbnRlciBtYXRlcmlhbCBkbyBxdWFsIG7Do28gZGV0w6ltIG9zIGRpcmVpdG9zIGRlCmF1dG9yLCBvYnRldmUgYSBhdXRvcml6YcOnw6NvIGlycmVzdHJpdGEgZG8gcmVzcGVjdGl2byBkZXRlbnRvciBkZXNzZXMgZGlyZWl0b3MgcGFyYSBjZWRlciDDoApVRlBFIG9zIGRpcmVpdG9zIHJlcXVlcmlkb3MgcG9yIGVzdGEgTGljZW7Dp2EgZSBhdXRvcml6YXIgYSB1bml2ZXJzaWRhZGUgYSB1dGlsaXrDoS1sb3MgbGVnYWxtZW50ZS4gRGVjbGFyYSB0YW1iw6ltIHF1ZSBlc3NlIG1hdGVyaWFsIGN1am9zIGRpcmVpdG9zIHPDo28gZGUgdGVyY2Vpcm9zIGVzdMOhIGNsYXJhbWVudGUgaWRlbnRpZmljYWRvIGUgcmVjb25oZWNpZG8gbm8gdGV4dG8gb3UgY29udGXDumRvIGRvIGRvY3VtZW50byBlbnRyZWd1ZTsKZykgU2UgbyBkb2N1bWVudG8gZW50cmVndWUgw6kgYmFzZWFkbyBlbSB0cmFiYWxobyBmaW5hbmNpYWRvIG91IGFwb2lhZG8gcG9yIG91dHJhIGluc3RpdHVpw6fDo28gcXVlIG7Do28gYSBVRlBFLCBkZWNsYXJhIHF1ZSBjdW1wcml1IHF1YWlzcXVlciBvYnJpZ2HDp8O1ZXMgZXhpZ2lkYXMgcGVsbyByZXNwZWN0aXZvIGNvbnRyYXRvIG91IGFjb3Jkby4KCkEgVUZQRSBpZGVudGlmaWNhcsOhIGNsYXJhbWVudGUgbyhzKSBub21lKHMpIGRvKHMpIGF1dG9yIChlcykgZG9zIGRpcmVpdG9zIGRvIGRvY3VtZW50byBlbnRyZWd1ZSBlIG7Do28gZmFyw6EgcXVhbHF1ZXIgYWx0ZXJhw6fDo28sIHBhcmEgYWzDqW0gZG8gcHJldmlzdG8gbmEgYWzDrW5lYSBjKS4KRepositório InstitucionalPUBhttps://repositorio.ufpe.br/oai/requestattena@ufpe.bropendoar:22212019-10-25T13:16:37Repositório Institucional da UFPE - Universidade Federal de Pernambuco (UFPE)false |
dc.title.pt_BR.fl_str_mv |
Validating transformations of OO programs using the alloy analyzer |
title |
Validating transformations of OO programs using the alloy analyzer |
spellingShingle |
Validating transformations of OO programs using the alloy analyzer SILVA, Tarciana Dias da Engenharia de software Linguagem de programação |
title_short |
Validating transformations of OO programs using the alloy analyzer |
title_full |
Validating transformations of OO programs using the alloy analyzer |
title_fullStr |
Validating transformations of OO programs using the alloy analyzer |
title_full_unstemmed |
Validating transformations of OO programs using the alloy analyzer |
title_sort |
Validating transformations of OO programs using the alloy analyzer |
author |
SILVA, Tarciana Dias da |
author_facet |
SILVA, Tarciana Dias da |
author_role |
author |
dc.contributor.authorLattes.pt_BR.fl_str_mv |
http://lattes.cnpq.br/6930023635739057 |
dc.contributor.advisorLattes.pt_BR.fl_str_mv |
http://lattes.cnpq.br/3977760354511853 |
dc.contributor.author.fl_str_mv |
SILVA, Tarciana Dias da |
dc.contributor.advisor1.fl_str_mv |
SAMPAIO, Augusto Cezar Alves |
dc.contributor.advisor-co1.fl_str_mv |
MOTA, Alexandre Cabral |
contributor_str_mv |
SAMPAIO, Augusto Cezar Alves MOTA, Alexandre Cabral |
dc.subject.por.fl_str_mv |
Engenharia de software Linguagem de programação |
topic |
Engenharia de software Linguagem de programação |
description |
Program transformation is current practice in software development, especially refactoring. However, in general, there is no precise specification of these transformations and, when it exists, it is neither proved sound nor validated systematically, which can cause static semantic or behavioural errors in the resulting programs, after each transformation application. This work proposes a strategy to validate program transformation specifications grounded by a formal infrastructure built predominantly in Alloy. In this work we focus on transformations in languages that support OO features such as Java, ROOL, the calculus of refinement of component and object-oriented systems known as rCOS and an OO language with reference semantic. The scope of this work, concerning the strategy implementation, is a subset of Java. Complementarily to testing, formal languages provide a mathematically solid reasoning mechanism to establish the soundness of transformations. Unfortunately, a complete formal treatment for transformations in OO languages is ruled out because even for Java there is no complete formal semantics. We investigate the trustworthiness of program transformations by using an approach that combines (bounded) model finding and testing. Our Alloy formal infrastructure comprises four main Alloy models: (1) a metamodel for a subset of OO language features and a set of predicates that capture the static semantics, where the main predicate is able to determine if a program is well–formed; (2) a Transformation-Specific model for each program transformation being investigated; (3) a Static Semantics Validator model; and (4) a Dynamic Validator Model, which generates all possible instances (according to the scope specified), each one having a representation of a program before and after the transformation application. If any instances are generated in (3), this means that there is a failure in the transformation specification. So, in this case it is necessary to correct the specification and re–submit it to the Alloy Analyzer. This process is repeated until no more instances are found by the Static Semantics Validator Model. Hence, the instances generated by the Dynamic Validator model only represent well–formed programs since it is only applied after the Static Semantics Validator model. Afterwards, the instances generated by (4) are further submitted to a tool, called Alloy-To-Java Translator, which generates Java programs corresponding to these instances along with tests to be applied in each side of the transformation. These programs are finally validated with regard to dynamic semantic problems, based on these automatic tests generated in (4). In this way, a developer can implement the transformations with some confidence on their behavioural preservation, after validating the transformation specifications using the proposed framework. The strategy we propose seems promising since it is an alternative to validate transformations even when a complete semantics of the languages is not available. The results of the validation of a representative set of transformations found in the literature show that some transformation issues, concerning both static and dynamic behaviour, can be detected. |
publishDate |
2017 |
dc.date.issued.fl_str_mv |
2017-08-23 |
dc.date.accessioned.fl_str_mv |
2019-07-08T18:30:23Z |
dc.date.available.fl_str_mv |
2019-07-08T18:30:23Z |
dc.type.status.fl_str_mv |
info:eu-repo/semantics/publishedVersion |
dc.type.driver.fl_str_mv |
info:eu-repo/semantics/doctoralThesis |
format |
doctoralThesis |
status_str |
publishedVersion |
dc.identifier.uri.fl_str_mv |
https://repositorio.ufpe.br/handle/123456789/31379 |
url |
https://repositorio.ufpe.br/handle/123456789/31379 |
dc.language.iso.fl_str_mv |
eng |
language |
eng |
dc.rights.driver.fl_str_mv |
Attribution-NonCommercial-NoDerivs 3.0 Brazil http://creativecommons.org/licenses/by-nc-nd/3.0/br/ info:eu-repo/semantics/openAccess |
rights_invalid_str_mv |
Attribution-NonCommercial-NoDerivs 3.0 Brazil http://creativecommons.org/licenses/by-nc-nd/3.0/br/ |
eu_rights_str_mv |
openAccess |
dc.publisher.none.fl_str_mv |
Universidade Federal de Pernambuco |
dc.publisher.program.fl_str_mv |
Programa de Pos Graduacao em Ciencia da Computacao |
dc.publisher.initials.fl_str_mv |
UFPE |
dc.publisher.country.fl_str_mv |
Brasil |
publisher.none.fl_str_mv |
Universidade Federal de Pernambuco |
dc.source.none.fl_str_mv |
reponame:Repositório Institucional da UFPE instname:Universidade Federal de Pernambuco (UFPE) instacron:UFPE |
instname_str |
Universidade Federal de Pernambuco (UFPE) |
instacron_str |
UFPE |
institution |
UFPE |
reponame_str |
Repositório Institucional da UFPE |
collection |
Repositório Institucional da UFPE |
bitstream.url.fl_str_mv |
https://repositorio.ufpe.br/bitstream/123456789/31379/5/TESE%20Tarciana%20Dias%20da%20Silva.pdf.jpg https://repositorio.ufpe.br/bitstream/123456789/31379/1/TESE%20Tarciana%20Dias%20da%20Silva.pdf https://repositorio.ufpe.br/bitstream/123456789/31379/2/license_rdf https://repositorio.ufpe.br/bitstream/123456789/31379/3/license.txt https://repositorio.ufpe.br/bitstream/123456789/31379/4/TESE%20Tarciana%20Dias%20da%20Silva.pdf.txt |
bitstream.checksum.fl_str_mv |
c466c733b782012a9847749b1fd81e36 68f76a63110f7a6a806f639bd7e014ea e39d27027a6cc9cb039ad269a5db8e34 bd573a5ca8288eb7272482765f819534 fbb13ecd109e39733edd5c82c8854e51 |
bitstream.checksumAlgorithm.fl_str_mv |
MD5 MD5 MD5 MD5 MD5 |
repository.name.fl_str_mv |
Repositório Institucional da UFPE - Universidade Federal de Pernambuco (UFPE) |
repository.mail.fl_str_mv |
attena@ufpe.br |
_version_ |
1802310842529611776 |