Generic Roles: Reducing Code Replication

Abstract

In partial fulfillment of requirements for the degree of Doctor of Philosophy in Informatics Enginnering by the Doctoral Program in Informatics EngineeringFor many years the concept of modularity has been considered a very important part in the development of large software systems. Modules help to manage the system’s complexity by decomposing it in smaller parts. These parts can be assigned to individuals or teams for development. Modules hide the information they manipulate behind an interface, allowing its developers to develop the module independently of any other module in the system. Developers can change the information their module manipulates and even the way it does it without the need to consult other developers, and breaking their code. This enables the interchangeability of modules, allowing one module to be substituted by another without further modifications to the system. It also reduces compiling time as modules can be precompiled. The concept of modularization lead to the dawn of several decompositions techniques, each with its own ideas on how a system should be decomposed into modules. For each decomposition technique and to help programmers extract the most benefits from modularization, several programming languages provide support for expressing modules. In object-oriented decomposition, for example, several programming languages provide support to define abstract data types, usually in the form of classes. Ideally, each module would capture one coherent concept that would deal with a set of coherent concerns related to the module’s concept. Unfortunately that is not always true. Sometimes, modules need to interact in more complicated and intertwined manners. Sometimes, the need to communicate with other modules lead one module to assume concerns that are not related to its main concern. This is, as argued by many authors, because only a single decomposition strategy is used . To avoid this we may need to use more than one decompositions strategy or extend an existing one. Code clones are an outcome of the lack of other decomposition strategies, among others sources. Code cloning in a system is considered a bad thing with multiple drawbacks. One of the more known problems is the inconsistent maintenance: bugs are fixed in some clones, but not in others. Another major objection to the use of cloning is that it degrades the design of the system over time. Awkward, verbose designs lead to the accumulation of irrelevant code that ends up obscuring the original intent of the code. In this dissertation we study the reduction of the code replication using modularity as a cornerstone around which our solution must be based. We intend to reduce code replication using another kind of module, which we can use to extend the object-oriented strategy. The module that we will study is the role. Roles have been used to specify na object’s behavior related to a specific collaboration in the modeling stages of a system. But in the implementation that specification is merged with all the object’s other collaboration behaviors, inside a class. It is a purpose of this dissertation to take the specification from the design phase to the implementation phase and study its impact on the code replication problem. The solution proposed in this dissertation is to use roles as a way to compose classes and thus reducing code replication. To pursue this goal a role language is designed and a suitable compiler is implemented. The JavaStage language allows a programmer to “program with roles”. It introduces several features like a powerful renaming mechanism and to state role dependencies easily. Using JavaStage and roles we were able to identify several refactorings that enables us to write the replicated code as roles thus removing the code clone. The use of these refactorings proved their value when applied to a series of case studies developed to assess the amount of duplicated code that could be removed using roles. As already mentioned, the modularity principles were followed throughout the design of the proposed solution and, to assess the reusability of roles, a role library was started. Its evolution corroborates the idea that roles are reusable modules and can be used as a compositional element.A modularidade é, já há muitos anos, vista como uma peça importante no desenvolvimento de sistemas informáticos de grandes dimensões. Os módulos ajudam a gerir a complexidade do sistema decompondo-o em várias partes mais pequenas que podem ser adjudicadas a um indivíduo ou a uma equipa para desenvolvimento. Os módulos encapsulam a informação que manipulam e o modo como a manipulam, permitindo assim aos seus autores desenvolvêlo independentemente dos outros módulos do sistema. Os autores de um módulo podem, inclusivé, alterar o modo de representação da informação à medida das suas necessidades, ou até alterar o modo de a manipular, sem consultar os autores dos outros módulos e sem quebrar os módulos destes. Isto permite a permutação de módulos, podendo assim um módulo ser substituído por outro sem que o sistema sofra outras alterações. Também permite um tempo de compilação mais rápido devido a poder-se pré-compilar os vários módulos. O conceito de modularização levou ao surgimento de várias estratégias de decomposição, cada uma com as suas ideias sobre como um sistema deveria ser decomposto em módulos. Para cada uma destas estragégias, e para ajudar os programadores a usufruir ao máximo dos benefícios da modularização, surgiram várias linguagens de programação com suporte para a representação de módulos. Por exemplo, na decomposição orientada a objetos, muitas linguagens permitem a definição de tipos abstratos de dados, normalmente na forma de classes. Idealmente, cada módulo capturaria um conceito coerente e esse conceito lidaria com um conjunto coerente de responsabilidades ligadas ao conceito principal do módulo. Infelizmente, não é assim. Por vezes os módulos precisam de interagir de forma mais complexa e interligada com outros módulos. Outras vezes a necessidade de comunicar com outros módulos leva-os a assumir responsabilidades que não estão de acordo com a sua “razão de ser”. Isto, como é argumentado por muitos autores, é uma consequência do uso de uma única estratégia de decomposição. Para evitar isto provavelmente necessita-se de uma outra forma de decomposição ou expandir uma já existente. O aparecimento de clones no código é uma consequência do uso de uma única estratégia de decomposição, entre outras causas. A presença de código repetido num sistema é considerada um mau indício e acarta muitas consequências nefastas. Um dos problemas mais conhecidos é a inconsistência na manutenção: os bugs são reparados em algumas instâncias do código repetido mas não em todas. Outro grande problema do uso de cópias de código é que o seu uso irá degradar o design do sistema a longo prazo. Isto leva à acumulação de código irrelevante que acaba por obscurecer o objectivo inicial do código. Nesta tese tenta-se estudar a redução de código repetido usando a modularidade como “pedra de toque” em torno da qual a nossa solução se baseará. Tencionámos reduzir a repetição de código usando outro tipo de módulo, que nos permita expandir a decomposição orientada a objetos. O módulo que iremos estudar será o role. Os roles têm vindo a ser usados para especificar o comportamento de um objeto em relação a outro objeto, dentro de uma colaboração, na etapa de modelação do sistema. Mas, na fase de implementação, essa especificação é agrupada com todos os comportamentos que o objeto exibe em todas as suas colaborações, dentro de uma classe. É um dos propósitos desta tese levar esta especificação desde a fase de modelação até à fase de implementação e estudar o seu impacto no problema de repetição de código. A solução proposta nesta dissertação é usar os roles como uma maneira de compor classes e assim reduzir a repetição de código. Para atingir este objectivo uma linguagem de programação que suporta roles será idealizada e um compilador adequado desenvolvido. A linguagem JavaStage permite a um programador “programar com roles”. Ela introduz algumas funcionalidades como um mecanismo de renomeação de métodos poderoso e uma forma de exprimir as dependências do role facilmente. Usando a JavaStage e os roles fomos capazes de identificar várias refactorings que nos permitem expressar o código presente nas várias repetições como roles e assim remover o código repetido associado. Estas refactorings mostraram o seu valor quando usadas numa série de casos de estudo que foram desenvolvidos com o propósito de avaliar a quantidade de código repetido que se poderia remover usando roles. Como já foi mencionado os princípios da modularidade foram seguidos ao longo da concepção da solução proposta e para avaliar a reutilização dos roles a construção de uma biblioteca de roles foi iniciada. A sua evolução corrobora a ideia de que os roles são módulos reutilizáveis e podem ser usados como um elemento composicional de classes