[pt] A existência de vários ambientes procedurais definidos para middlewares de Sistemas de TV Digital terrestre levou à criação de um framework conhecido como Globally Executable MHP (GEM). Esse padrão visa a harmonização de tais ambientes permitindo a execução global das aplicações. Nesse contexto, este trabalho descreve a construção de um ambiente de apresentação declarativo utilizando a API fornecida pelo GEM de forma a permitir a execução global do conteúdo declarativo produzido para o Sistema Brasileiro de TV Digital. / [en] The several procedural environment proposals for terrestrial Digital TV Systems led to the middleware framework recommendation known as Globally Executable MHP (GEM). This standard aims at the harmonization of such environments allowing the global execution of procedural applications but neglecting the declarative ones. In this context, this work describes the integration of the Ginga declarative environment using the API supplied by GEM and allowing the global execution of declarative contents produced for the Brazilian System of Digital TV (Sistema Brasileiro de TV Digital).

[pt] A linguagem Java foi definida tendo como foco a portabilidade. O código gerado pela compilação é interpretado por uma máquina virtual, e não diretamente pelo processador destino, como um programa em C. Este código intermediário, também conhecido como bytecode, é a chave da portabilidade de Java. Os Bytecodes Java usam uma pilha para manipular os operandos das instruções. O uso de pilha tem suas vantagens e desvantagens. Dentre as vantagens, podemos citar a simplicidade da implementação do compilador e da máquina virtual. A principal desvantagem é a redução na velocidade de execução dos programas, devido à necessidade de se mover os operandos para a pilha e retirar dela o resultado, gerando um aumento no número de instruções que devem ser processadas. Diversos estudos indicam que máquinas virtuais baseadas em registradores podem ser mais rápidas que as baseadas em pilha. Decidimos criar uma nova especificação de bytecodes, específicos para máquinas virtuais baseadas em registradores. Esperamos com isso obter um aumento no desempenho das aplicações. / [en] The Java language was created with a focus on portability. The code generated by the compiler is interpreted by a virtual machine, and not directly by the target processor, like programs written in C. This intermediate code, also known as bytecode, is the key to Java's portability. The Java Bytecodes use a stack to manipulate the instruction operands. The use of stack has its their pros and cons. Among the advantages, we can cite the simplicity of implementation of the compiler and virtual machine. On the other hand, there is a speed reduction in the program's execution, due to the need to move the operands to and from the stack, and retrieve results from it, increasing the number of instructions that are processed. Much study has been done that indicating that register-based virtual machines can be faster than the ones based on stacks. Based on this, we decided to create a new bytecode specification, proper for a virtual machine based on registers. By doing this, we hope to obtain an increase in an application's performance.

[pt] Diferentes sistemas de componentes de software, tais como CORBA, COM e JavaBeans, apresentam diferentes modelos de objetos e sistemas de tipos. Essas diferenças dificultam a integração de componentes oriundos de sistemas distintos e, conseqüentemente, são uma barreira para o reuso desses componentes. Neste trabalho, defendemos a tese de que uma linguagem interpretada com um determinado conjunto de mecanismos reflexivos, aliada à compatibilidade estrutural de tipos, oferece um mecanismo de composição adequado tanto para a conexão dinâmica de componentes, quanto para a interoperabilidade entre diferentes sistemas de componentes. Esse mecanismo de composição realiza em tempo de execução as tarefas de conexão, adaptação, implementação e verificação de tipos de componentes, e trata de uma maneira uniforme componentes de diferentes sistemas, permitindo que estes sejam conectados de uma forma transparente. O mecanismo de composição que propomos se baseia em um modelo que privilegia a flexibilidade em tempo de execução. Esse modelo de composição é composto por dois elementos principais. O primeiro elemento é um modelo de objetos que definimos com a finalidade de poder representar componentes dos diferentes sistemas tratados neste trabalho. Assim, esse modelo de objetos faz o papel de um modelo integrador, isto é, um modelo sob o qual objetos de diferentes sistemas podem ser representados e interagir de forma transparente. O segundo elemento de nosso modelo de composição é um padrão de projeto (design pattern) para a implementação de bindings entre linguagens interpretadas e sistemas de componentes. Esse padrão de projeto, chamado Dynamic Language Binding, não utiliza a técnica tradicional de stubs. Ao invés disso, ele utiliza mecanismos de reflexividade e tipagem dinâmica para implementar tanto proxies genéricos, que podem representar qualquer componente de um determinado sistema, quanto adaptadores genéricos, que permitem a implementação de componentes utilizando a própria linguagem de composição. Como instrumento de validação da nossa proposta, descrevemos uma implementação do modelo de composição denominada LuaOrb. LuaOrb utiliza a linguagem interpretada Lua como linguagem de composição dinâmica, e integra os sistemas CORBA, COM e Java. / [en] Different component systems, such as CORBA, COM, and Java, have different object models and type systems. Such differences make the interoperability between components of distinct systems more difficult, and thus are an obstacle for component reuse. In this dissertation, we argue that an interpreted language with a specific set of reflexive mechanisms, together with a type system with structural compatibility, offers a composition mechanism suitable for dynamic component connection and for interoperability between different component systems. This composition mechanism performs at runtime the tasks of verifying types, connecting, adapting and implementing components, and handles components of different systems in a uniform way, allowing them to be connected transparently. The proposed composition mechanism is based on a model that favors flexibility at runtime. This composition model is composed of two major elements. The first one is an object model, defined in order to represent components of the different systems addressed in this dissertation. Thus, this object model performs the role of a unifying model, that is, a model in which objects from different systems can interact and be represented transparently. The second element of our composition model is a design pattern to implement bindings between interpreted languages and component systems. This design pattern, named Dynamic Language Binding, does not use the traditional stubs technique. Instead of this, it uses reflection and dynamic typing to implement generic proxies, which can represent any component of a specific system, and generic adapters, which allow component implementations using the composition language itself. In order to validate our proposal, we describe the LuaOrb system, which is an implementation of our composition model. LuaOrb uses the interpreted language Lua as its dynamic composition language, and integrates the systems CORBA, COM and Java.

[pt] Contexto Injeção de Dependência (DI) é um mecanismo comumente aplicado para desacoplar classes de suas dependências com o objetivo de prover uma melhor modularização do software. No contexto de Java, a existência de uma especificação de DI e frameworks populares, como o Spring, facilitam o emprego de DI em projetos de software. Entretanto, más práticas de implementação de DI podem trazer más consequências, como maior acoplamento, dificultando alcançar o principal objetivo de DI. Apesar de a literatura sugerir a existência de anti-padrões de DI, não há uma documentação detalhada de tais más práticas. Em adição, não há evidência da ocorrência e da percepção de utilidade dos mesmos do ponto de vista de desenvovedores. Objetivos Nosso objetivo é revisar os anti-padrões de DI reportados com o objetivo de analisar sua completude e propor um novo catálogo de anti-padrões de DI para Java. Método Nós propomos um catálogo contendo 12 anti-padrões de DI para Java. Nós selecionamos 4 projetos open-source e 2 projetos closed-source que adotam um framework de DI e desenvolvemos uma ferramenta que analisa estaticamente a ocorrência dos anti-padrões de DI candidatos no código fonte das aplicações. Em adição, nós conduzimos uma pesquisa por meio de entrevistas face a face com três desenvolvedores experientes que regularmente aplicam DI em seus projetos. Nós estendemos a pesquisa com o objetivo de obter a percepção de um conjunto de 15 desenvolvedores experientes e novatos por meio de um questionário online Resultados Ao menos 9 anti-padrões de DI apareceram frequentemente nos projetos de software analisados. Em adição, a avaliação recebida dos desenvolvedores confirmaram a relevância do catálogo. Por fim, os respondentes expressaram o desejo de refatorar as instâncias de antipadrões de DI propostas. Conclusões O catálogo contém anti-padrões de DI que ocorrem na prática e são úteis. Compartilhar com praticantes da indústria os permitirá evitar a introdução de anti-padrões em seus projetos de software. / [en] Background Dependency Injection (DI) is a commonly applied mechanism to decouple classes from their dependencies in order to provide better modularization of software. In the context of Java, the availability of a DI specification and popular frameworks, such as Spring, facilitate DI usage in software projects. However, bad DI implementation practices can have negative consequences, such as increasing coupling, hindering the achievement of DI s main goal. Even though the literature suggests the existence of DI anti-patterns, there is no detailed documentation of such bad practices. Moreover, there is no evidence on their occurrence and perceived usefulness from the developer s point of view. Aims Our goal is to review the reported DI anti-patterns in order to analyze their completeness and to propose and evaluate a novel catalog of Java DI anti-patterns. Method We propose a catalog containing 12 Java DI anti-patterns. We selected 4 opensource and 2 closed-source software projects that adopt a DI framework and developed a tool to statically analyze the occurrence of the candidate DI anti-patterns within their source code. Also, we conducted a survey through face to face interviews with three experienced developers that regularly apply DI. We extended the survey in order to gather the perception of a set of 15 expert and novice developers through an online questionnaire. Results At least 9 different DI anti-patterns appeared frequently in the analyzed projects. In addition, the feedback received from the developers confirmed the relevance of the catalog. Besides, the respondents expressed their willingness to refactor instances of anti-patterns from source code. Conclusions The catalog contains Java DI anti-patterns that occur in practice and are useful. Sharing it with practitioners may help them to avoid such anti-patterns.