Spelling suggestions: "subject:"era??o dde c?dio."" "subject:"era??o dde c?dig.""
1 |
Uma linguagem espec?fica de dom?nio para gera??o de testes de performanceMarinho, 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??oMedeiros 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 BGomes, 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??oMedeiros 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?sicosMoura, 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 smartcardsGomes, 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.0695 seconds