We extend the Jinni mobile agent architecture with a multicast network transport layer, an agent-to-agent delegation mechanism and a reflection based Prolog-to-Java interface. To ensure that our agent infrastructure runs efficiently, independently of router-level multicast support, we describe a blackboard based algorithm for locating a randomly roaming agent. As part of the agent-to-agent delegation mechanism, we describe an alternative to code-fetching mechanism for stronger mobility of mobile agents with less network overhead. In the context of direct and reflection based extension mechanisms for Jinni, we describe the design and the implementation of a reflection based Prolog-to-Java interface. The presence of subtyping and method overloading makes finding the most specific method corresponding to a Prolog call pattern fairly difficult. We describe a run-time algorithm which provides accurate handling of overloaded methods beyond Java's reflection package's limitations.

Submitted by Fabio Sobreira Campos da Costa (fabio.sobreira@ufpe.br) on 2016-08-08T12:21:17Z No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) 2016-pbsf-msc.pdf: 596422 bytes, checksum: be9375166fe6e850180863e08b7997d8 (MD5) / Made available in DSpace on 2016-08-08T12:21:17Z (GMT). No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) 2016-pbsf-msc.pdf: 596422 bytes, checksum: be9375166fe6e850180863e08b7997d8 (MD5) Previous issue date: 2016-03-04 / FACEPE / Implicit or indirect control flow allows a transfer of control to a procedure without having to call the procedure explicitly in the program. Implicit control flow is a staple design pattern that adds flexibility to system design. However, it is challenging for a static analysis to compute or verify properties about a system that uses implicit control flow. When a static analysis encounters a procedure call, the analysis usually approximates the call’s behavior by a summary, which conservatively generalizes the effects of any target of the call. In previous work, a static analysis that verifies security properties was developed for Android apps, but failed to achieve high precision in the presence of implicit control flow. This work presents static analyses for two types of implicit control flow that frequently appear in Android apps: Java reflection and Android intents. In our analyses, the summary of a method is the method’s signature. Our analyses help to resolve where control flows and what data is passed. This information improves the precision of downstream analyses, which no longer need to make conservative assumptions about implicit control flow, while maintaining the soundness. We have implemented our techniques for Java. We enhanced an existing security analysis with a more precise treatment of reflection and intents. In a case study involving ten real-world Android apps that use both intents and reflection, the precision of the security analysis was increased on average by two orders of magnitude. The precision of two other downstream analyses was also improved. / Fluxo de controle implícito, ou indireto, permite que haja uma transferência de controle para um procedimento sem que esse procedimento seja invocado de forma explícita pelo programa. Fluxo de controle implícito é um padrão de projeto comum e bastante utilizado na prática, que adiciona flexibilidade no design de um sistema. Porém, é um desafio para uma análise estática ter que computar e verificar propriedades sobre um sistema que usa fluxos de controle implícito. Quando uma análise estática encontra uma chamada a uma procedimento, geralmente a análise aproxima o comportamento da chamada de acordo com o sumário do método, generalizando de uma forma conservadora os efeitos da chamada ao procedimento. Em trabalho anterior, uma análise estática de segurança foi desenvolvida para aplicações Android, mas falhou em obter uma alta precisão na presença de fluxos de controle implícito. Este trabalho apresenta uma análise estática para dois tipos de fluxos de controle implícito que aparecem frequentemente em aplicações Android: Java reflection e Android intents. Nas nossas análises, o sumário de um método é a assinatura do método. Nossas análises ajudam a descobrir para onde o controle flui e que dados estão sendo passados. Essa informação melhora a precisão de outras análises estáticas, que não precisam mais tomar medidas conservadoras na presença de fluxo de controle implícito. Nós implementamos a nossa técnica em Java. Nós melhoramos uma análise de segurança existente através de um tratamento mais preciso em casos de reflection e intents. Em um estudo de caso envolvendo dez aplicações Android reais que usam reflection e intents, a precisão da análise de segurança aumentou em duas ordens de magnitude. A precisão de outras duas análises estáticas também foi melhorada.

<p>This report presents the results of a thesis project that surveys and designs about the issue “Feature Model for Adaptive Computing”. In this project, there are two main issues, first one is about the Feature Modeling, and the second is how to use this Feature Modeling for adaptive computing.</p><p>In this thesis report, at the beginning, we present the problem we expected to solve and introduce some background information, including the knowledge of feature model and adaptive computing. Then we explain our solution and evaluate this solution. At the end of this report, we give a short conclusion about our thesis project and feature work.</p>

<p>This report presents the results of a master level thesis project that analyzes and designs about the issue “Framework for Flexible Connectors with Java Reflection Proxies”. In this project, there are two main issues; first one is about finding a way to implement the function of a connector. And the other one is to build a framework for flexible connectors.</p><p>By studying on Java’s dynamic proxy, we find we can use it to implement the function of a connector. When building a connector chain, we use an important Java technique--Java Reflection API.</p>

This report presents the results of a thesis project that surveys and designs about the issue “Feature Model for Adaptive Computing”. In this project, there are two main issues, first one is about the Feature Modeling, and the second is how to use this Feature Modeling for adaptive computing. In this thesis report, at the beginning, we present the problem we expected to solve and introduce some background information, including the knowledge of feature model and adaptive computing. Then we explain our solution and evaluate this solution. At the end of this report, we give a short conclusion about our thesis project and feature work.

This report presents the results of a master level thesis project that analyzes and designs about the issue “Framework for Flexible Connectors with Java Reflection Proxies”. In this project, there are two main issues; first one is about finding a way to implement the function of a connector. And the other one is to build a framework for flexible connectors. By studying on Java’s dynamic proxy, we find we can use it to implement the function of a connector. When building a connector chain, we use an important Java technique--Java Reflection API.

Nearly seven hundreds of students each year apply for informatics' studies at University of economics, Prague (UEP). At the beginning, each one must complete two courses related to programming - Introduction to Programming and Fundamentals of Software Engineering. Both courses produce a lot of outputs -- simpler home works or more complex semestral projects -- which must be assessed by the teachers. Especially assessment of early home works is laboring and routine which makes it perfect candidate for automation. The goal of this work is to suggest the best suitable way how to implement this automation at UEP. Since mass courses make troubles universities all around the world there is already a lot of existing solutions how to automate evaluation of programming courses. First two chapters summarize the effort to find the most interesting ones and present them to the Czech audience. Because existing solutions are really sophisticated but does not provide white box tests support needed at UEP the rest of this thesis is not about creating own new automatic assessment system but about creating a middleware which can handle the problem mentioned. The middleware called Duckapter makes usage of Java reflection API easier and is downloadable from project website http://code.google.com/p/duckapter. Using them, the teachers can provide white box tests inside the black box (unit) tests which are supported by the most of the current automatic assessment systems.

This master's thesis describes the analysis, design and implementation of an application for automatic generation of UML class diagram. Application is designed as a web service, which provides remote access, especially permanent actuality of generated class diagram. Input of the service is a compiled application written for C# .NET or Java platform. The reader is acquainted with basics of reverse engineering of mentioned platforms and with structure of UML class diagram. Then are these knowledge applied in design and implementation of the service. The main goal is to facilitate and accelerate the activities of software development team members.

<p>In this research paper, it evaluates the benefits achievable from static testing framework by analyzing and transforming the <em>JUnit3.8 </em>source code and static execution of transformed code. Static structure enables us to analyze the code statically during creation and execution of test cases. The concept of research is by now well established in static analysis and testing development. The research approach is also increasingly affecting the static testing process and such research oriented work has proved particularly valuable for those of us who want to understand the reflective behavior of <em>JUnit3.8 Framework</em>.</p><p><em> JUnit3.8 Framework</em> uses <em>Java Reflection API</em> to invoke core functionality (test cases creation and execution) dynamically. However, <em>Java Reflection API</em> allows developers to access and modify structure and behavior of a program.  Reflection provides flexible solution for creating test cases and controlling the execution of test cases. Java reflection helps to encapsulate test cases in a single object representing the test suite. It also helps to associate each test method with a test object. Where reflection is a powerful tool to perform potential operations, on the other hand, it limits static analysis. Static analysis tools often cannot work effectively with reflection.</p><p>In order to avoid the reflection, <em>Static Testing Framework</em> provides a static platform to analyze the <em>JUnit3.8</em> source code and transform it into non-reflective version that emulates the dynamic behavior of <em>JUnit3.8</em>. The transformed source code has possible leverage to replace reflection with static code and does same things in an execution environment of <em>Static Testing Framework</em> that reflection does in <em>JUnit3.8</em>. More besides, the transformed code also enables execution environment of <em>Static Testing Framework</em> to run test methods statically. In order to measure the degree of efficiency, the implemented tool is evaluated. The evaluation of <em>Static Testing Framework</em> draws results for different Java projects and these statistical data is compared with <em>JUnit3.8</em> results to measure the effectiveness of <em>Static Testing Framework</em>. As a result of evaluation, <em>STF</em> can be used for static creation and execution of test cases up to <em>JUnit3.8</em> where test cases are not creating within a test class and where real definition of constructors is not required. These problems can be dealt as future work by introducing a middle layer to execute test fixtures for each test method and by generating test classes as per real definition of constructors.</p>

In this research paper, it evaluates the benefits achievable from static testing framework by analyzing and transforming the JUnit3.8 source code and static execution of transformed code. Static structure enables us to analyze the code statically during creation and execution of test cases. The concept of research is by now well established in static analysis and testing development. The research approach is also increasingly affecting the static testing process and such research oriented work has proved particularly valuable for those of us who want to understand the reflective behavior of JUnit3.8 Framework. JUnit3.8 Framework uses Java Reflection API to invoke core functionality (test cases creation and execution) dynamically. However, Java Reflection API allows developers to access and modify structure and behavior of a program.  Reflection provides flexible solution for creating test cases and controlling the execution of test cases. Java reflection helps to encapsulate test cases in a single object representing the test suite. It also helps to associate each test method with a test object. Where reflection is a powerful tool to perform potential operations, on the other hand, it limits static analysis. Static analysis tools often cannot work effectively with reflection. In order to avoid the reflection, Static Testing Framework provides a static platform to analyze the JUnit3.8 source code and transform it into non-reflective version that emulates the dynamic behavior of JUnit3.8. The transformed source code has possible leverage to replace reflection with static code and does same things in an execution environment of Static Testing Framework that reflection does in JUnit3.8. More besides, the transformed code also enables execution environment of Static Testing Framework to run test methods statically. In order to measure the degree of efficiency, the implemented tool is evaluated. The evaluation of Static Testing Framework draws results for different Java projects and these statistical data is compared with JUnit3.8 results to measure the effectiveness of Static Testing Framework. As a result of evaluation, STF can be used for static creation and execution of test cases up to JUnit3.8 where test cases are not creating within a test class and where real definition of constructors is not required. These problems can be dealt as future work by introducing a middle layer to execute test fixtures for each test method and by generating test classes as per real definition of constructors.