• Refine Query
  • Source
  • Publication year
  • to
  • Language
  • 6
  • Tagged with
  • 6
  • 6
  • 6
  • 6
  • 6
  • 4
  • 4
  • 4
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • About
  • The Global ETD Search service is a free service for researchers to find electronic theses and dissertations. This service is provided by the Networked Digital Library of Theses and Dissertations.
    Our metadata is collected from universities around the world. If you manage a university/consortium/country archive and want to be added, details can be found on the NDLTD website.
1

Uma linguagem espec?fica de dom?nio para gera??o de testes de performance

Marinho, Thiago David dos Santos 30 August 2016 (has links)
Submitted by Automa??o e Estat?stica (sst@bczm.ufrn.br) on 2017-03-15T00:19:14Z No. of bitstreams: 1 ThiagoDavidDosSantosMarinho_DISSERT.pdf: 1356454 bytes, checksum: 1729cdbb721d0f506e383c0cbe6eb72e (MD5) / Approved for entry into archive by Arlan Eloi Leite Silva (eloihistoriador@yahoo.com.br) on 2017-03-17T00:21:08Z (GMT) No. of bitstreams: 1 ThiagoDavidDosSantosMarinho_DISSERT.pdf: 1356454 bytes, checksum: 1729cdbb721d0f506e383c0cbe6eb72e (MD5) / Made available in DSpace on 2017-03-17T00:21:08Z (GMT). No. of bitstreams: 1 ThiagoDavidDosSantosMarinho_DISSERT.pdf: 1356454 bytes, checksum: 1729cdbb721d0f506e383c0cbe6eb72e (MD5) Previous issue date: 2016-08-30 / Este trabalho apresenta a ferramenta GenMeter, composta por: (i) uma linguagem espec?fica de dom?nio utilizada para descrever textualmente testes de performance; e (ii) um componente que utiliza os testes descritos para gerar projetos em diferentes plataformas de execu??o de testes de performance. O objetivo ? utilizar os conceitos definidos na linguagem para abstrair os conceitos de cada plataforma, que muitas vezes s?o modelados diferentemente, quanto ? nomenclatura e/ou estrutura, e at? dependentes da ferramenta, ao inv?s de apenas do dom?nio. A ferramenta proposta oferece suporte para testes de servi?os SOAP, REST e de aplica??es web para JMeter e Silk Performer. Ela tamb?m permite a customiza??o para novos tipos de testes e plataformas alvo. Foram feitos estudos para avaliar o uso da ferramenta: 3 testes de aplica??es Web, REST e SOAP foram reescritos na linguagem espec?fica de dom?nio (DSL - domain specific language) e ent?o foram gerados projetos nas plataformas de destino, para que fossem executados. A partir dos ajustes e novas implementa??es necess?rios para a gera??o dos projetos, obteve-se feedback referente a capacidade de customiza??o da ferramenta em rela??o aos tipos de aplica??es e caracter?sticas de plataformas e organiza??es. Al?m disso, os scripts tamb?m foram avaliados em rela??o ? sua concis?o: al?m dos testes implementados com a DSL e com o Silk Performer, foram criados testes com a ferramenta Gatling.io (tamb?m baseados no teste da empresa). Comparou-se o total de palavras necess?rias para a defini??o de cada teste, al?m da rela??o entre o n?mero de palavras reservadas e o total de palavras, e a rela??o entre o n?mero de palavras reservadas fora do contexto e o total de palavras reservadas. Os testes criados com a DSL GenMeter possuem, em m?dia, 59,15% menos palavras em rela??o aos testes de Silk Performer e 39,43% em rela??o aos testes de Gatling.io, com exce??o de um tipo de teste, em que a especifica??o com a DSL ficou com pouco mais que o dobro (138,35%) de palavras. Na segunda compara??o, em m?dia, os testes com a GenMeter apresentaram um percentual de 56,33% de palavras reservadas em rela??o ao total, contra 39,98% do Silk Performer e 67,03% do Gatling.io. Esta compara??o pode ser interpretada como a quantidade de informa??o adicional que o usu?rio precisa fornecer pra cada linguagem, al?m das estruturas fornecidas pela mesma. J? na terceira compara??o, que pode ser interpretada como o quanto a sintaxe da linguagem hospedeira pode interferir na visualiza??o das informa??es dos testes, a GenMeter teve em m?dia 23,57% de palavras reservadas fora do contexto em rela??o ao total de palavras reservadas, contra 53,38% do Silk Performer e 54,60% do Gatling. Dessa forma, foi poss?vel observar os benef?cios de utilizar a DSL para diferentes tipos de aplica??es, customizando-a de acordo com determinados conceitos e caracter?sticas de plataformas e organiza??es. / This work presents GenMeter, a tool composed of: (i) a domain-specific language (DSL) used to describe textually performance tests; and (ii) a component that uses those described test specifications to generate projects in different performance test execution platforms. The purpose is to use concepts defined in the language to abstract the concepts of each platform, which are often modeled differently regarding nomenclature and/or structure and even dependent on the tool rather than just the domain. The proposed tool supports SOAP, REST and web applications performance tests to JMeter and Silk Performer. It also allows customization to new test types and target platforms. Studies were conducted to evaluate the use of the tool: 3 tests of web applications, REST and SOAP services have been rewritten in the DSL and then were generated projects to the target platforms, to be executed. After the adaptation and new implementations necessary for the project generation, we obtained feedback regarding the ability to customize the tool for the applications types and platforms and organizations features. Moreover, the scripts were also evaluated for their conciseness: tests were created with Gatling.io tool (also based on the company?s test) to compare with existing DSL and Silk Performer tests. Our study also compared the total number of words needed to define each test and the relation between the number of reserved words and the total number of words; and the relationship between the number of reserved words out of context, and the total of reserved words. Tests created with GenMeter have, on average, 59,15% less words in relation to Silk Performer tests and 39,43% in relation to Gatling.io tests, except by one test type, where GenMeter?s tests get little more than the double (138,35%) of words. In second comparison, on average, tests with the GenMeter presented a percentage of 56.33% of reserved words in relation to the total, against 39.98% from Silk Performer and 67.03% from Gatling.io. This first comparison can be interpreted as the amount of additional information that the user needs to provide for each language, in addition to the structures provided by them. In the third comparison, which can be interpreted as how the syntax of the host language may interfere with viewing of the test information, GenMeter had an average of 23.57% of reserved words out of context relative to the total of reserved words against 53.38% from Silk Performer and 54.60% from Gatling. Thus, it was possible to observe the benefits of using DSL for different types of applications, customizing it according to certain concepts and features platforms and organizations.
2

Gera??o autom?tica de hardware apartir de especifica??es formais: estendendo uma abordagem de tradu??o

Medeiros Junior, Ivan Soares de 27 April 2012 (has links)
Made available in DSpace on 2014-12-17T15:48:01Z (GMT). No. of bitstreams: 1 IvanSMJ_DISSERT.pdf: 2894212 bytes, checksum: 3acb921ac87239ee36be60cb2e15b0e6 (MD5) Previous issue date: 2012-04-27 / A remo??o de inconsist?ncias em um projeto ? menos custosa quando realizadas nas etapas iniciais da sua concep??o. A utiliza??o de M?todos Formais melhora a compreens?o dos sistemas al?m de possuir diversas t?cnicas, como a especifica??o e verifica??o formal, para identificar essas inconsist?ncias nas etapas iniciais de um projeto. Por?m, a transforma??o de uma especifica??o formal para uma linguagem de programa??o ? uma tarefa n?o trivial. Quando feita manualmente, ? uma tarefa pass?vel da inser??o de erros. O uso de ferramentas que auxiliem esta etapa pode proporcionar grandes benef?cios ao produto final a ser desenvolvido. Este trabalho prop?e a extens?o de uma ferramenta cujo foco ? a tradu??o autom?tica de especifica??es em CSPm para Handel-C. CSP ? uma linguagem de descri??o formal adequada para trabalhar com sistemas concorrentes. Handel-C ? uma linguagem de programa??o cujo resultado pode ser compilado diretamente para FPGA's. A extens?o consiste no aumento no n?mero de operadores CSPm aceitos pela ferramenta, permitindo ao usu?rio definir processos locais, renomear canais e utilizar guarda booleana em escolhas externas. Al?m disto, propomos tamb?m a implementa??o de um protocolo de comunica??o que elimina algumas restri??es da composi??o paralela de processos na tradu??o para Handel-C, permitindo que a comunica??o entre m?ltiplos processos possa ser mapeada de maneira consistente e que a mesma somente ocorra quando for autorizada.
3

BSmart: desenvolvimento rigoroso de aplica??es Java Card com base no m?todo formal B

Gomes, Bruno Emerson Gurgel 19 November 2007 (has links)
Made available in DSpace on 2014-12-17T15:47:44Z (GMT). No. of bitstreams: 1 BrunoEGG.pdf: 1320681 bytes, checksum: 897ca75ef7f0e564e8588d949fcc67d5 (MD5) Previous issue date: 2007-11-19 / Coordena??o de Aperfei?oamento de Pessoal de N?vel Superior / Java Card technology allows the development and execution of small applications embedded in smart cards. A Java Card application is composed of an external card client and of an application in the card that implements the services available to the client by means of an Application Programming Interface (API). Usually, these applications manipulate and store important information, such as cash and confidential data of their owners. Thus, it is necessary to adopt rigor on developing a smart card application to improve its quality and trustworthiness. The use of formal methods on the development of these applications is a way to reach these quality requirements. The B method is one of the many formal methods for system specification. The development in B starts with the functional specification of the system, continues with the application of some optional refinements to the specification and, from the last level of refinement, it is possible to generate code for some programming language. The B formalism has a good tool support and its application to Java Card is adequate since the specification and development of APIs is one of the major applications of B. The BSmart method proposed here aims to promote the rigorous development of Java Card applications up to the generation of its code, based on the refinement of its formal specification described in the B notation. This development is supported by the BSmart tool, that is composed of some programs that automate each stage of the method; and by a library of B modules and Java Card classes that model primitive types, essential Java Card API classes and reusable data structures / A tecnologia Java Card permite o desenvolvimento e execu??o de pequenas aplica??es embutidas em smart cards. Uma aplica??o Java Card ? composta por um cliente, externo ao cart?o, e por uma aplica??o contida no cart?o que implementa os servi?os dispon?veis ao cliente por meio de uma Application Programming Interface (API). Usualmente, essas aplica??es manipulam e armazenam informa??es importantes, tais como valores monet?rios ou dados confidenciais do seu portador. Sendo assim, faz-se necess?rio adotar um maior rigor no processo de desenvolvimento de uma aplica??o smart card, visando melhorar a sua qualidade e confiabilidade. O emprego de m?todos formais como parte desse processo ? um meio de se alcan?ar esses requisitos de qualidade. O m?todo formal B ?e um dentre os diversos m?todos formais para a especifica??o de sistemas. O desenvolvimento em B tem in?cio com a especifica??o funcional do sistema, continua com a aplica??o opcional de refinamentos ? especifica??o e, a partir do ?ltimo n?vel de refinamento, ? poss?vel a gera??o de c?digo para alguma linguagem de programa??o. O formalismo B conta com bom suporte de ferramentas e a sua aplica??o a Java Card mostra-se bastante adequada, uma vez que a especifica??o e desenvolvimento de APIs ?e o ponto forte de B. O m?todo BSmart aqui proposto visa promover o desenvolvimento rigoroso de aplica??es Java Card a partir da gera??o de c?digo da aplica??o com base em refinamentos da sua especifica??o formal descrita na nota??o B. O processo de desenvolvimento descrito no m?todo ? apoiado pela ferramenta BSmart, a qual constitui-se por alguns programas que automatizam cada etapa do m?todo; e por uma biblioteca de m?dulos B e classes Java Card que modelam tipos primitivos, classes essenciais da API Java Card e estruturas de dados reutiliz?veis
4

Gera??o autom?tica de hardware a partir de especifica??es formais: estendendo uma abordagem de tradu??o

Medeiros Junior, Ivan Soares de 27 April 2012 (has links)
Made available in DSpace on 2014-12-17T15:48:02Z (GMT). No. of bitstreams: 1 IvanSMJ_DISSERT.pdf: 2894212 bytes, checksum: 3acb921ac87239ee36be60cb2e15b0e6 (MD5) Previous issue date: 2012-04-27 / Coordena??o de Aperfei?oamento de Pessoal de N?vel Superior / Removing inconsistencies in a project is a less expensive activity when done in the early steps of design. The use of formal methods improves the understanding of systems. They have various techniques such as formal specification and verification to identify these problems in the initial stages of a project. However, the transformation from a formal specification into a programming language is a non-trivial task and error prone, specially when done manually. The aid of tools at this stage can bring great benefits to the final product to be developed. This paper proposes the extension of a tool whose focus is the automatic translation of specifications written in CSPM into Handel-C. CSP is a formal description language suitable for concurrent systems, and CSPM is the notation used in tools support. Handel-C is a programming language whose result can be compiled directly into FPGA s. Our extension increases the number of CSPM operators accepted by the tool, allowing the user to define local processes, to rename channels in a process and to use Boolean guards on external choices. In addition, we also propose the implementation of a communication protocol that eliminates some restrictions on parallel composition of processes in the translation into Handel-C, allowing communication in a same channel between multiple processes to be mapped in a consistent manner and that improper communication in a channel does not ocurr in the generated code, ie, communications that are not allowed in the system specification / A remo??o de inconsist?ncias em um projeto ? menos custosa quando realizada nas etapas iniciais da sua concep??o. A utiliza??o de M?todos Formais melhora a compreens?o dos sistemas al?m de possuir diversas t?cnicas, como a especifica??o e verifica??o formal, para identificar essas inconsist?ncias nas etapas iniciais de um projeto. Por?m, a transforma??o de uma especifica??o formal para uma linguagem de programa??o ? uma tarefa n?o trivial. Quando feita manualmente, ? uma tarefa pass?vel da inser??o de erros. O uso de ferramentas que auxiliem esta etapa pode proporcionar grandes benef?cios ao produto final que ser? desenvolvido. Este trabalho prop?e a extens?o de uma ferramenta cujo foco ? a tradu??o autom?tica de especifica??es em CSPM para Handel-C. CSP ? uma linguagem de descri??o formal adequada para trabalhar com sistemas concorrentes, CSPM ? a nota??o utilizada pelas ferramentas de apoio da linguagem. Handel-C ? uma linguagem de programa??o cujo resultado pode ser compilado diretamente para FPGA s. A extens?o consiste no aumento no n?mero de operadores CSPM aceitos pela ferramenta, permitindo ao usu?rio definir processos locais, renomear canais e utilizar guarda booleana em escolhas externas. Al?m disto, propomos tamb?m a implementa??o de um protocolo de comunica??o que elimina algumas restri??es da composi??o paralela de processos na tradu??o para Handel-C, permitindo que a comunica??o em um mesmo canal entre m?ltiplos processos possa ser mapeada de maneira consistente e que no c?digo gerado n?o ocorra comunica??es indevidas em um canal, ou seja, comunica??es que n?o s?o permitidas na especifica??o do sistema
5

Metodologia para modelagem, valida??o e programa??o de controladores l?gicos industriais usando statecharts b?sicos

Moura, Raimundo Santos 09 June 2009 (has links)
Made available in DSpace on 2014-12-17T14:54:52Z (GMT). No. of bitstreams: 1 RaimundoSM.pdf: 1084567 bytes, checksum: b0c04a2886a533d2f22958c9fda16e38 (MD5) Previous issue date: 2009-06-09 / Coordena??o de Aperfei?oamento de Pessoal de N?vel Superior / Due of industrial informatics several attempts have been done to develop notations and semantics, which are used for classifying and describing different kind of system behavior, particularly in the modeling phase. Such attempts provide the infrastructure to resolve some real problems of engineering and construct practical systems that aim at, mainly, to increase the productivity, quality, and security of the process. Despite the many studies that have attempted to develop friendly methods for industrial controller programming, they are still programmed by conventional trial-and-error methods and, in practice, there is little written documentation on these systems. The ideal solution would be to use a computational environment that allows industrial engineers to implement the system using high-level language and that follows international standards. Accordingly, this work proposes a methodology for plant and control modelling of the discrete event systems that include sequential, parallel and timed operations, using a formalism based on Statecharts, denominated Basic Statechart (BSC). The methodology also permits automatic procedures to validate and implement these systems. To validate our methodology, we presented two case studies with typical examples of the manufacturing sector. The first example shows a sequential control for a tagged machine, which is used to illustrated dependences between the devices of the plant. In the second example, we discuss more than one strategy for controlling a manufacturing cell. The model with no control has 72 states (distinct configurations) and, the model with sequential control generated 20 different states, but they only act in 8 distinct configurations. The model with parallel control generated 210 different states, but these 210 configurations act only in 26 distinct configurations, therefore, one strategy control less restrictive than previous. Lastly, we presented one example for highlight the modular characteristic of our methodology, which it is very important to maintenance of applications. In this example, the sensors for identifying pieces in the plant were removed. So, changes in the control model are needed to transmit the information of the input buffer sensor to the others positions of the cell / Com o advento da inform?tica industrial muitos esfor?os t?m sido realizados para o desenvolvimento de nota??es e sem?nticas usadas para classificar e descrever diferentes tipos de sistemas, sobretudo na fase de modelagem. Tais esfor?os fornecem a infraestrutura necess?ria para a solu??o de alguns problemas reais de engenharia e a constru??o de sistemas pr?ticos que visam, principalmente, o aumento da produtividade, qualidade e seguran?a de processos. Al?m disso, apesar de muitos estudos tentarem desenvolverm?todos amig?veis para programa??o de controladores l?gicos industriais, estes ainda s?o programados atrav?s de m?todos convencionais no estilo tentativa e erro e, na pr?tica, usualmente n?o existe documenta??o escrita para esses sistemas. A solu??o ideal para este problema seria usar um ambiente computacional que permita engenheiros industriais implementar o sistema usando linguagens de alto n?vel e que obede?am padr?es internacionais. Baseado nessa perspectiva, este trabalho descreve um procedimento sistem?tico para modelar a planta e o controle de sistemas com din?mica discreta que incluem opera??es sequenciais, paralelas e temporizadas, usando um formalismo baseado nos Statecharts, denominado Statecharts B?sicos (SCB). A metodologia tamb?m permite procedimentos autom?ticos de verifica??o e implementa??o desses sistemas. A valida??o da metodologia foi realizada por meio de estudos de casos com exemplos t?picos de aplica??es da ?rea de manufatura. O primeiro exemplo apresenta um controle sequencial para um etiquetador de pe?as e serve para ilustrar a depend?ncia entre os dispositivos da planta. O segundo exemplo discute mais de uma estrat?gia de controle para uma c?lula de manufatura. O modelo da c?lula usada nos exemplos possui 72 configura??es poss?veis e, com um controle sequencial, a planta ficou restrita a 8 configura??es, enquanto que com um controle paralelo, a planta atuou em 26 configura??es diferentes, sendo, portanto, um controle menos restritivo. Por fim, foi apresentado um exemplo para ressaltar a caracter?stica modular da nossa metodologia, que ? de suma import?ncia para a manutenibilidade de aplica??es. Neste exemplo, os sensores para identifica??o de pe?as presentes na planta da c?lula de manufatura foram removidos, gerando a necessidade de altera??es no modelo do controle para propagar as informa??es do sensor de entrada de pe?as para as outras posi??es da c?lula.
6

Desenvolvimento formal de aplica??es para smartcards

Gomes, Bruno Emerson Gurgel 01 June 2012 (has links)
Made available in DSpace on 2014-12-17T15:46:59Z (GMT). No. of bitstreams: 1 BrunoEGG_TESE.pdf: 2215931 bytes, checksum: 5d86c012a04f884e6dec73c92c1d88ef (MD5) Previous issue date: 2012-06-01 / Coordena??o de Aperfei?oamento de Pessoal de N?vel Superior / Smart card applications represent a growing market. Usually this kind of application manipulate and store critical information that requires some level of security, such as financial or confidential information. The quality and trustworthiness of smart card software can be improved through a rigorous development process that embraces formal techniques of software engineering. In this work we propose the BSmart method, a specialization of the B formal method dedicated to the development of smart card Java Card applications. The method describes how a Java Card application can be generated from a B refinement process of its formal abstract specification. The development is supported by a set of tools, which automates the generation of some required refinements and the translation to Java Card client (host) and server (applet) applications. With respect to verification, the method development process was formalized and verified in the B method, using the Atelier B tool [Cle12a]. We emphasize that the Java Card application is translated from the last stage of refinement, named implementation. This translation process was specified in ASF+SDF [BKV08], describing the grammar of both languages (SDF) and the code transformations through rewrite rules (ASF). This specification was an important support during the translator development and contributes to the tool documentation. We also emphasize the KitSmart library [Dut06, San12], an essential component of BSmart, containing models of all 93 classes/interfaces of Java Card API 2:2:2, of Java/Java Card data types and machines that can be useful for the specifier, but are not part of the standard Java Card library. In other to validate the method, its tool support and the KitSmart, we developed an electronic passport application following the BSmart method. We believe that the results reached in this work contribute to Java Card development, allowing the generation of complete (client and server components), and less subject to errors, Java Card applications. / As aplica??es para smart cards representam um mercado que cresce a cada ano. Normalmente, essas aplica??es manipulam e armazenam informa??es que requerem garantias de seguran?a, tais como valores monet?rios ou informa??es confidenciais. A qualidade e a seguran?a do software para cart?es inteligentes pode ser aprimorada atrav?s de um processo de desenvolvimento rigoroso que empregue t?cnicas formais da engenharia de software. Neste trabalho propomos o m?todo BSmart, uma especializa??o do m?todo formal B dedicada ao desenvolvimento de aplica??es para smart cards na linguagem Java Card. O m?todo descreve, em um conjunto de etapas, como uma aplica??o smart card pode ser gerada a partir de refinamentos em sua especifica??o formal. O desenvolvimento ? suportado por um conjunto de ferramentas, automatizando a gera??o de parte dos refinamentos e a tradu??o para as aplica??es Java Card cliente (host) e servidora (applet). Ressalta-se que o processo de especifica??o e refinamento descrito no m?todo foi formalizado e verificado utilizando o pr?prio m?todo B, com o aux?lio da ferramenta Atelier B [Cle12a]. Destaca-se que a aplica??o Java Card ? traduzida a partir do ?ltimo passo de refinamento, denominado de implementa??o. A especifica??o dessa tradu??o foi feita na linguagem ASF+SDF [BKV08]. Inicialmente, descreveu-se as gram?ticas das linguagens B e Java (SDF) e, em uma etapa posterior, especificou-se as transforma??es de B para Java Card atrav?s de regras de reescrita de termos (ASF). Essa abordagem foi um importante aux?lio durante o processo de tradu??o, al?m de servir ao prop?sito de document?lo. Cumpre destacar a biblioteca KitSmart [Dut06, San12], componente essencial ao m?todo BSmart, que inclui modelos em B de todas as 93 classes/interfaces da API Java Card na vers?o 2:2:2, dos tipos de dados Java e Java Card e de m?quinas que podem ser ?teis ao especificador, mas que n?o est?o presentes na API padr?o. Tendo em vista validar o m?todo, seu conjunto de ferramentas e a biblioteca KitSmart, procedeu-se com o desenvolvimento, seguindo o m?todo BSmart, de uma aplica??o de passaporte eletr?nico. Os resultados alcan?ados neste trabalho contribuem para o desenvolvimento smart card, na medida em que possibilitam a gera??o de aplica??es Java Card completas (cliente e servidor) e menos sujeitas a falhas.

Page generated in 0.0965 seconds