Which Method-Stereotype Changes Are Indicators of Code Smells?
Total Page：16
File Type：pdf, Size：1020Kb
Rochester Institute of Technology RIT Scholar Works Presentations and other scholarship Faculty & Staff Scholarship 9-23-2018 Which Method-Stereotype Changes are Indicators of Code Smells? Michael J. Decker Bowling Green State University Christian D. Newman Rochester Institute of Technology Natalia Dragan Kent State University Michael L. Collard The University of Akron Johnathan I. Maletic Kent State University See next page for additional authors Follow this and additional works at: https://scholarworks.rit.edu/other Recommended Citation M. J. Decker, C. D. Newman, N. Dragan, M. L. Collard, J. I. Maletic and N. A. Kraft, "[Research Paper] Which Method-Stereotype Changes are Indicators of Code Smells?," 2018 IEEE 18th International Working Conference on Source Code Analysis and Manipulation (SCAM), Madrid, 2018, pp. 82-91, doi: 10.1109/ SCAM.2018.00017 This Conference Paper is brought to you for free and open access by the Faculty & Staff Scholarship at RIT Scholar Works. It has been accepted for inclusion in Presentations and other scholarship by an authorized administrator of RIT Scholar Works. For more information, please contact [email protected]. Authors Michael J. Decker, Christian D. Newman, Natalia Dragan, Michael L. Collard, Johnathan I. Maletic, and Nicholas A. Kraft This conference paper is available at RIT Scholar Works: https://scholarworks.rit.edu/other/959 Which Method-Stereotype Changes are Indicators of Code Smells? Michael J. Decker Christian D. Newman Natalia Dragan Department of Computer Science Department of Software Engineering Departmnet of Management and Information Bowling Green State University Rochester Institute of Technology Systems Bowling Green, OH, USA Rochester, NY, USA Kent State University, Kent, OH, USA [email protected] [email protected] [email protected] Michael L. Collard Jonathan I. Maletic Nicholas A. Kraft Department of Computer Science Department of Computer Science ABB Corborate Research The University of Akron Kent State University Raleigh, NC, USA Akron, OH, USA Kent, OH, USA [email protected] [email protected] [email protected] Abstract— A study of how method roles evolve during the and the system as a whole. A number of researchers have lifetime of a software system is presented. Evolution is examined leveraged stereotypes for various applications by analyzing when the stereotype of a method changes. [9][10][11][12][13][14]. Two simple examples of stereotypes Stereotypes provide a high-level categorization of a method’s are accessor (e.g. getter) and mutator (e.g. setter). Accessor behavior and role, and also provide insight into how a method methods allow for information to be read from an object while interacts with its environment and carries out tasks. The study preventing modification of the object. Mutator methods allow covers 50 open-source systems and 6 closed-source systems. one to modify the state of an object. In the next section, we Results show that method behavior with respect to stereotype is present a complete set of stereotypes and definitions. highly stable and constant over time. Overall, out of all the history In the work presented here, we are interested in how the examined, only about 10% of changes to methods result in a stereotype of a particular method changes during the lifetime of change in their stereotype. Examples of methods that change stereotype are further examined. A select number of these types a system. In particular, we want to determine if a method’s of changes are indicators of code smells. stereotype changes often or rarely. What types of changes in stereotype are most common? Are some types of these changes Keywords—method stereotypes, software change, software hazardous? Or innocuous? Our goal is to determine what is the evolution, code smells, empirical norm, with regards to changes in stereotype, so we may let developers and project managers know when something is abnormal, and thus potentially a problem. I. INTRODUCTION To this end, we have undertaken an empirical study of the A typical, non-trivial, software system is in a constant state complete version history of 50 open-source C++ systems. This of evolution over its lifetime [1]. At points in this lifetime, its provides us with almost 1.4 million changes to methods. We design may degrade or be broken by the evolutionary change. also separately examined 6 closed-source systems with nearly This eventually requires developers to spend time redesigning 54K changes to methods. Each of the methods that change are parts (or the entirety) of the system. Code smells [2][3] are one examined over time and what happened to their (automatically indicator of poor design or design degradation. Thus, there is computed) stereotype is recorded. Our first goal is to examine research examining ways to automatically identify certain code the stability of method stereotypes during evolution. That is, do smells with the goal of warning users when a system’s design is method stereotypes change as methods change? potentially degrading [4][5][6]. Our second goal is to determine what types of changes from The work presented here takes a similar approach. That is, one stereotype to another stereotype are potentially hazardous. we are trying to understand what types of changes to a system Intuitively, a method should not change drastically from its are potentially hazardous to the design. Here, we are specifically original intent. If there is a drastic change in its role and/or interested in how individual methods change over time. While behavior this may be an indication of a problem. However, a change to an individual method will not typically degrade a clearly systems do evolve and the role of methods must evolve system’s design, changes to large sets of methods can. Hence, in some manner. There may also be changes that fix poor we empirically investigate and propose a relatively simple designs and these types of changes may be reflected in the abstraction and lightweight approach that indicates when a stereotype of a method. We seek to answer the following change is a potential problem. research questions: The granularity of change we are examining is at the level of • RQ1: Is a method’s stereotype stable as it evolves? a method. The abstraction we are using is the idea of method • RQ2: What types of method-stereotype changes occur? stereotypes [7][8]. Method stereotypes represent a rich • RQ3: Which method-stereotype changes are benign or abstraction of the role and behavior of a method within its class suspicious? XXX-X-XXXX-XXXX-X/XX/$XX.00 ©20XX IEEE To answer these questions, we perform three separate types identify non_const_get methods which, unlike a get method, can of analysis. First, we analyze stereotype changes in terms of the additionally mutate an object’s state (i.e., can have an additional change in behavior they represent and the consequences they stereotype from the Structural Mutator category). An alternative have on the source code. Then, we perform an empirical tool for stereotype identification [8] that works only for Java investigation on 50 open-source software systems. Finally, we programs is also available but appears to be less robust than finish with a manual investigation of method-stereotype StereoCode, hence the use of StereoCode. changes. We also examine 6 closed-source systems to see if the results are similar to the open-source code. The contributions of TABLE I. METHOD STEREOTYPE TAXONOMY. EACH STEREOTYPE this work are as follows: CATEGORY IS LISTED WITH ITS SET OF STEREOTYPES. • An empirical study that demonstrates that the stereotype Stereotype Stereotype Description of a method is very stable as it evolves within a system. Category • A set of defined stereotype transitions and their get Returns a data member. Returns Boolean value that is potential impact on a system’s design. predicate not a data member. Structural • A manual evaluation of potentially problematic Returns info about data Accessor property stereotype transitions. members. Returns information via a The paper is organized as follows. In Section II, we discuss void-accessor method stereotypes in detail. In Section III we discuss our parameter. set Sets a data member. motivation for investigating stereotype stability. In Section IV, Structural command Performs a complex change to we discuss the stability of method stereotypes and introduce a Mutator non-void-command the object’s state. taxonomy of method-stereotype changes. In Section V, we constructor, discuss how we collect data for an empirical and manual copy-constructor, Creates and/or destroys Creational investigation. In Section VI, we present the results of an destructor, objects. empirical and manual investigation of the method stereotypes factory and relate it to the taxonomy. Finally, in Sections VII and VIII, Works with objects the threats to validity and conclusion are provided. collaborator (parameter, local or return Collaborational value). Changes only an external II. METHOD STEREOTYPES controller object’s state (not this). We now provide a brief introduction to method stereotypes. Does not read/change the The work of Dragan et al. [7] [15][16] introduces a taxonomy incidental object’s state. No calls to for method stereotypes, which we show in TABLE I. A method other class methods. Degenerate Does not read/change the stereotype concisely represents behavioral aspects of a method. stateless object’s state. One call to Method stereotypes are separated into five broad categories: other class methods. Structural Accessors – query the state of an object on which it is empty Has no statements. called; Structural Mutators – modify the state of an object on which it is called; Creational – create/provide new objects; III. MOTIVATION AND RELATED WORK Collaborational – work on objects pertaining to classes other Method stereotypes have been shown to be a useful and than itself; and Degenerate – no use of the object’s state and powerful abstraction of a method’s role and behavior.