Generic roles: reducing code replication

• Main Author: Barbosa, F.S.
• Publication Date: 2013
• Language: eng
• Source: Repositórios Científicos de Acesso Aberto de Portugal (RCAAP)
• Download full: http://hdl.handle.net/10400.11/2073

For 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.