On Using UML Diagrams to Identify and Assess Software Design Smells

Deficiencies in software design or architecture can severely impede and slow down the software development and maintenance progress. Bad smells and anti-patterns can be an indicator for poor software design and suggest for refactoring the affected source code fragment. In recent years, multiple techniques and tools have been proposed to assist software engineers in identifying smells and guiding them through corresponding refactoring steps. However, these detection tools only cover a modest amount of smells so far and also tend to produce false positives which represent conscious constructs with symptoms similar or identical to actual bad smells (e.g., design patterns). These and other issues in the detection process demand for a code or design review in order to identify (missed) design smells and/or re-assess detected smell candidates. UML diagrams are the quasi-standard for documenting software design and are often available in software projects. In this position paper, we investigate whether (and to what extent) UML diagrams can be used for identifying and assessing design smells. Based on a description of difficulties in the smell detection process, we discuss the importance of design reviews. We then investigate to what extent design documentation in terms of UML2 diagrams allows for representing and identifying software design smells. In particular, 14 kinds of design smells and their representability in UML class and sequence diagrams are analyzed. In addition, we discuss further challenges for UML-based identification and assessment of bad smells

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

Handling High-Level Model Changes Using Search Based Software Engineering

Model-Driven Engineering (MDE) considers models as first-class artifacts during the software lifecycle. The number of available tools, techniques, and approaches for MDE is increasing as its use gains traction in driving quality, and controlling cost in evolution of large software systems. Software models, defined as code abstractions, are iteratively refined, restructured, and evolved. This is due to many reasons such as fixing defects in design, reflecting changes in requirements, and modifying a design to enhance existing features. In this work, we focus on four main problems related to the evolution of software models: 1) the detection of applied model changes, 2) merging parallel evolved models, 3) detection of design defects in merged model, and 4) the recommendation of new changes to fix defects in software models. Regarding the first contribution, a-posteriori multi-objective change detection approach has been proposed for evolved models. The changes are expressed in terms of atomic and composite refactoring operations. The majority of existing approaches detects atomic changes but do not adequately address composite changes which mask atomic operations in intermediate models. For the second contribution, several approaches exist to construct a merged model by incorporating all non-conflicting operations of evolved models. Conflicts arise when the application of one operation disables the applicability of another one. The essence of the problem is to identify and prioritize conflicting operations based on importance and context – a gap in existing approaches. This work proposes a multi-objective formulation of model merging that aims to maximize the number of successfully applied merged operations. For the third and fourth contributions, the majority of existing works focuses on refactoring at source code level, and does not exploit the benefits of software design optimization at model level. However, refactoring at model level is inherently more challenging due to difficulty in assessing the potential impact on structural and behavioral features of the software system. This requires analysis of class and activity diagrams to appraise the overall system quality, feasibility, and inter-diagram consistency. This work focuses on designing, implementing, and evaluating a multi-objective refactoring framework for detection and fixing of design defects in software models.Ph.D.Information Systems Engineering, College of Engineering and Computer ScienceUniversity of Michigan-Dearbornhttp://deepblue.lib.umich.edu/bitstream/2027.42/136077/1/Usman Mansoor Final.pdfDescription of Usman Mansoor Final.pdf : Dissertatio

Model-based source code refactoring with interaction and visual cues

Refactoring source code involves the developer in a myriad of program detail that can obscure the design changes that they actually wish to bring about. On the other hand, refactoring a UML model of the code makes it easier to focus on the program design, but the burdensome task of applying the refactorings to the source code is left to the developer. In an attempt to obtain the advantages of both approaches, we propose a refactoring approach where the interaction with the developer takes place at the model level, but the actual refactoring occurs on the source code itself. We call this approach model-based source code refactoring and implement it in this paper using two tools: (1) Design-Imp enables the developer to use interactive search-based design exploration to create a UML-based desired design from an initial design extracted from the source code. It also provides visual cues to improve developer comprehension during the design-level refactoring process and to help the developer to discern between promising and poor refactoring solutions. (2) Code-Imp then refactors the original source so that it has the same functional behavior as the original program, and a design close to the one produced in the design exploration phase, that is, a design that has been confirmed as “desirable” by the developer. We evaluated our approach involving interaction and visual cues with industrial developers refactoring three Java projects, comparing it with an approach using interaction without visual cues and a fully automated approach. The results show that our approach yields refactoring sequences that are more acceptable both to the individual developer and to a set of independent expert refactoring evaluators. Furthermore, our approach removed more code smells and was evaluated very positively by the experiment participants.</p

Risk Containers – A Help or Hindrance to Practitioners?

Finding problems at the design stage reduces the cost to resolve them. Previous studies have indicated that error-proneness risks can be isolated into risk containers created from architectural designs, to help mitigate such risks early on. Here we describe an ongoing experiment to establish whether presenting designs as a collection of such containers helps practitioners manage the isolated risks. Participants must identify cyclic dependencies that could result in error-proneness and assess the impact of design changes. The emerging results suggest it takes participants longer to locate cyclic dependencies in collections of container diagrams than it does in a single diagram representing the whole design. Participants who reviewed collections of container diagrams tended to identify more cyclic dependencies correctly than those using a single diagram. Although, the results suggest that presenting a design as a collection of containers has no overall bearing on a participant’s ability to correctly identify impacts of design changes, in cases where changes span multiple container diagrams no errors in change impact detection were observed. Errors were observed when assessing the same change using a single diagram representing the whole design