A heuristic-based approach to code-smell detection

Encapsulation and data hiding are central tenets of the object oriented paradigm. Deciding what data and behaviour to form into a class and where to draw the line between its public and private details can make the difference between a class that is an understandable, flexible and reusable abstraction and one which is not. This decision is a difficult one and may easily result in poor encapsulation which can then have serious implications for a number of system qualities. It is often hard to identify such encapsulation problems within large software systems until they cause a maintenance problem (which is usually too late) and attempting to perform such analysis manually can also be tedious and error prone. Two of the common encapsulation problems that can arise as a consequence of this decomposition process are data classes and god classes. Typically, these two problems occur together – data classes are lacking in functionality that has typically been sucked into an over-complicated and domineering god class. This paper describes the architecture of a tool which automatically detects data and god classes that has been developed as a plug-in for the Eclipse IDE. The technique has been evaluated in a controlled study on two large open source systems which compare the tool results to similar work by Marinescu, who employs a metrics-based approach to detecting such features. The study provides some valuable insights into the strengths and weaknesses of the two approache

A critical comparison of approaches to resource name management within the IEC common information model

Copyright @ 2012 IEEEElectricity network resources are frequently identified within different power systems by inhomogeneous names and identities due to the legacy of their administration by different utility business domains. The IEC 61970 Common Information Model (CIM) enables network modeling to reflect the reality of multiple names for unique network resources. However this issue presents a serious challenge to the integrity of a shared CIM repository that has the task of maintaining a resource manifest, linking network resources to master identities, when unique network resources may have multiple names and identities derived from different power system models and other power system applications. The current approach, using CIM 15, is to manage multiple resource names within a singular CIM namespace utilizing the CIM “IdentifiedObject” and “Name” classes. We compare this approach to one using additional namespaces relating to different power systems, similar to the practice used in CIM extensions, in order to more clearly identify the genealogy of a network resource, provide faster model import times and a simpler means of supporting the relationship between multiple resource names and identities and a master resource identity.This study is supported by the UK National Grid and Brunel University

Methodology of process models creation when using the software tool enterprise architect

A continuous improvement of business processes is a must for any company that wants to stay in the market. Customers requiring better and better products and services force all enterprises to think continuously about improving of their business processes. Such an approach is based on a good understanding and measuring of an existing process and, thus, from the resulting stimuli of its improvement. A software (SW) tool called Enterprise Architect enables, among others, to model individual business processes. The main objective of business processes modelling is to create a correct specification of these processes and to analyse their properties. The purpose of business processes modelling is to create such an abstraction of a process, which would enable to understand all its activities and all relationships existing between these activities on the one hand and roles represented by capabilities of people and facilities involved in a given process. The objective of this paper is to create a uniform methodology of business processes modelling when using the SW tool Enterprise Architect.Process model methodology of modeling activity process modelling area

Improving Semantic Transparency of Committee-Designed Languages through Crowd-sourcing

International audienceCommittee-designed languages such as those of the OMG consor-tium are widely used in both industry and academia. These lan-guages seem to be used increasingly by users with no technical background for the visualization, documentation and specification of workflows, data and software systems. However, according to several studies on these languages, the used visual notations do not seem to convey any particular semantics and the recognition of such notations is not perceptually immediate. This lack of se-mantic transparency increases the cognitive load to differentiate concepts from each other and slows down recognition and learning of the language constructs. This paper proposes a process, which leverages the crowd-sourcing to improve the semantic transparency of such languages. We believe that involving end-users in the de-sign process of the languages visual notations should increase the expressiveness of these languages and then their acceptance for a wide range of novice-users

Aspectual Templates in UML

UML Templates allow to capture models whose some of their constituents are parameters. This construct is general enough to be used in many ways, such as generic class representation, Design Pattern modeling, view or aspect-oriented modeling (AOM). In this paper, we concentrate on this last usage and the specific characteristics of so called ''Aspectual Templates". Such templates can be applied to enrich existing models as far as they conform to a required model. Template parameters are exploited here to specify some required model, so that they must be constrained to form a full model structure. After recall of UML templates and their metamodel, we present the specificities of their aspectual interpretation, existing works and identify the issues. Then we show how standard UML templates can be enhanced to capture aspectual ones. For this, a specialization of the UML template metamodel is detailed and OCL constraints are formulated due to this specific interpretation and its proper mechanisms. As a result, this metamodel specialization is fully compatible with the existing one so that aspectual templates are full UML standard ones. Finally, we present an algorithm which constructs the result of the application of an Aspectual Template to a model. This algorithm also works for aspectual template to template application. Presented results were implemented and made available in the EMF (Eclipse Modeling Framework) technology

WARP Business Intelligence System

Continuous delivery (CD) facilitates the software releasing process. Because the use of continuous integration and deployment pipelines, allows software to be tested several times before going into production. In Business Intelligence (BI), software releases tend to be manual and deprived of pipelines, versions control might also be deficient because of the project nature, which involves data and it’s impossible to version. How to apply CD concepts to BI to an existing project where legacy code is extended and there is no version control over project objects? Only few organizations have an automated release process for their BI projects. Because due to projects nature it is difficult to implement CD to the full extent. Thus, the problem was tackled in stages, first the implementation of version control, that works for the organization, then the establishment of the necessary environments to proceed with the pipelines and finally the creation of a test pipeline for one of the BI projects, proving the success of this approach. To evaluate the success of this solution the main beneficiaries (stakeholders and engineers) were asked to answer some questionnaires regarding their experience with the data warehouse before and after the use of CD. Because each release is tested before going into production, the use of CD will improve software quality in the long run as well as it allows software to be released more frequently.Continuous Delivery (CD) permite que as releases de software aconteçam em qualquer momento sem problemas associados, utilizando pipelines de integração e de deployment. Desta forma, o software é testado várias vezes antes de ser instalado em produção. Em Business Intelligence (BI), as releases são tendencialmente manuais, sem pipelines e devido à natureza do projecto (dados) o controlo de versões tende a ser inexistente. Como aplicar o conceito de CD num contexto de BI a projetos de grandes dimensões, com legacy code extenso e sem controlo de versões? Apenas algumas organizações têm um processo automático de releases para os seus projectos de BI, porque devido à natureza dos projetos que envolvem dados, é difícil implementar CD. Tendo em conta os estes factores, o problema foi abordado por etapas, em primeiro lugar procedeu-se à implementação de um controlo de versões, que se adapte às necessidades da organização. O passo seguinte foi a criação do ambiente necessário para prosseguir com a instalação de pipelines e para terminar, a terceira etapa, consistiu na criação de uma pipeline de teste para um dos projectos de BI, comprovando assim o sucesso da solução proposta. Para avaliar o sucesso desta solução os principais beneficiários (stakeholders e engenheiros) foram convidados a preencher questionários, que permitem avaliar a sua experiência com o data warehouse antes e depois da utilização da solução proposta neste trabalho. Como cada release é testada antes de ser instalada em produção, garantindo que possíveis erros já foram encontrados previamente, o uso de CD melhorará a qualidade do software a longo prazo e permitirá que as releases ocorram com mais frequência

Visually Characterizing Source Code Changes

International audienceRevision Control Systems (e.g., SVN, Git, Mercurial) include automatic and advanced merging algorithms that help developers to merge their modifications with development repositories. While these systems can help to textually detect conflicts, they do not help to identify the semantic consequences of a change. Unfortunately, there is little support to help release masters (integrators) to take decisions about the integration of changes into the system release. Most of the time, the release master needs to read all the modified code, check the diffs to build an idea of a change, and dig for details from related unchanged code to understand the context and potential impact of some changes. As a result, such a task can be overwhelming. In this article we present a visualization tool to support integrators of object-oriented programs in comprehending changes. Our approach named Torch characterizes changes based on structural informa- tion, authors and symbolic information. It mixes text-based diff information with visual representation and metrics characterizing the changes. The current implementation of our approach analyses Smalltalk programs, and thus we de- scribe our experiments applying it to Pharo, a large open-source system. We also report on the evaluations of our approach by release masters and developers of several open-source projects