A Research Plan to Characterize, Evaluate, and Predict the Impacts of Behavioral Decay in Design Patterns Derek Reimanis Department of Computer Science Montana State University Bozeman, MT 59717-3880 1+ (406) 994-4780 derek.reimanis@cs.montana.edu ABSTRACT Although significant work has been made towards understanding design pattern structural decay, little work has been made towards We propose a research plan to further the understanding of design understanding behavioral decay. Behavioral decay refers to the pattern evolution. Current research into design pattern evolution deterioration of the runtime design of a system. Behavioral decay focuses on the structural elements of decay, which is realized as is complementary to structural decay, yet a large gap and dearth of structural grime. We plan to expand the current state of research research is evident. The exploration of behavioral decay in design by introducing the notion of behavioral grime, or unwanted patterns will yield greater insights into the benefits and detriments artifacts that appear at run-time in a pattern. This form of grime of utilizing design patterns. may be transparent to the current analysis models. We seek to classify types of grime into taxonomy, evaluate each type in terms This paper is organized as follows: Section 2 discusses related of impacts on technical debt and quality in the pattern and system work. Section 3 outlines the current challenges in the field, as a whole, and predict future occurrences of behavioral grime. including research gaps and relevant problems. Section 4 outlines Studies are designed for each of these respective goals. The research objectives. Section 5 describes the approach. Section 6 results of this research will further the understanding of design identifies the threats to the validity of the proposed study, and patterns, assisting practitioners and researchers alike. section 7 provides concluding remarks. Categories and Subject Descriptors 2. BACKGROUND AND RELATED WORK D.2.4 [Software Engineering]: Software/Program Verification – Formal Methods; D.2.8 [Software Engineering]: Metrics – 2.1 Technical Debt product metrics; D.2.11 [Software Engineering]: Software Technical debt (TD) is a metaphor coined by Ward Cunningham Architectures – Patterns to describe the gap between the current state of a software system and the ideal state [7]. TD captures the effects of decisions that sacrifice good design principles for on-time delivery. Many times General Terms these decisions take the form of shortcuts or workarounds in code Measurement, Design, Experimentation, Verification. that complete the task at hand, but at the expense of decreased quality. Principal and interest are two attributes of TD. Given a Keywords task to implement, principal refers to the cost in effort to complete Software Behavior, Software Architecture, Design Patterns, the task. Interest refers to the gap between maintenance costs Formalization, Software Decay, Technical Debt under ideal conditions versus conditions where maintenance is higher due to accrued debt from tasks where TD is not repaid. Effectively managing TD is multi-faceted problem, where the 1. INTRODUCTION need to implement new features must be leveraged with the need Design patterns embody recurring solutions to common object- to refactor. oriented problems in software development. Patterns are design decisions that are reusable, maintainable, and attempt to minimize Tom et al. performed a systematic literature review of the current re-design in the future [12]. However, the evolution of design state of TD in academic literature [29]. The study reports that patterns is controversial. The original intent of the pattern may many of the difficulties of managing TD are a result of poor become obscured for many reasons, including new developers problem definition and representative models. As an outcome of contributing to a pattern, or the unforeseen changes to elements this study, Tom et al. propose a fundamental framework of TD; participating in the pattern. Empirical work has shown that the this work follows this framework. structure of a pattern has the potential to decay as the pattern ages Tom et al.’s framework identifies architectural technical debt [14] [15] [17] [18] [19]. Furthermore, research has shown that the (ATD) as a specific type of TD that focuses on items originating structural decay of patterns results in decreased system quality and from the design or architecture of a software project. These are increased technical debt [8]. items such as modularity violations [30], architecture dependency issues [26], and design pattern decay [4] [14] [15] [17] [18] [19]. Several operational models for estimating TD have recently Copyright © 2015 for this paper by its authors. Copying permitted for surfaced in the field [6] [13] [23] [24] [25], however no single private and academic purposes. method has surfaced as a clear better approach, possibly because they fail to capture domain specific information in a system. 33 2.2 Software Quality realized in the Unified Modeling Language (UML 2.0)1 and is an abstract language that generalizes each actor in a pattern to a Software quality has been categorized into a set of characteristics, single common role. Depending on the type of pattern, there will each of which is composed of related sub-characteristics. The be a number of possible roles. For example, the Observer pattern ISO-IEC 25010 Software Quality Specification formalizes a set of has a Subject role and an Observer role. Observer pattern eight characteristics to form an abstract model for measuring instances have classes that fulfill both these roles. quality [16]. These characteristics, or attributes, are evaluated to the extent to which a system realizes that characteristic. Several Dae-Kyoo Kim has shown that RBML alone is not sufficient for domain-agnostic quality models that realize this specification specifying patterns because it lacks constraint templates that limit have been developed. Two quality models, QMOOD and a robust the capabilities of roles [21]. In order to combat this, the Object- alternative QUAMOCO, have surfaced as operational quality Constraint Language (OCL) is used to provide necessary models [2] [31]. constraints to RBML models. 2.3 Software Behavior Preliminary research reveals that software behavior can be of two 3. CURRENT RESEARCH CHALLENGES types; internal and external. Internal behavior refers to the interior 3.1 Research Gaps mechanisms and API calls that occur during system runtime. The current knowledge base of design pattern grime features only Internal behaviors are not necessarily seen except at the point in structure-based disconformities, or grime that is captured from a time in which they are executing. In this manner, internal static snapshot of a pattern instance. This works seeks to extend behaviors are more a temporary artifact that exists only for the the knowledge base of pattern grime by considering behavior- duration of their execution. External behavior refers to the based disconformities, or grime that is captured during the external and observable result that the system produces. These runtime execution of a design pattern. In an effort to achieve this may be represented as system goals, and are the consequences of goal, the authors have identified the following research gaps. internal behaviors. That is, internal behaviors cause external 1. Characterization of Behavioral Grime: Structural grime behaviors. is incapable of capturing whether or not a design pattern is 2.4 Software Decay behaving as intended. A pattern instance may have no Code decay is a term that refers to the case where code is “harder structural grime, but the runtime execution of the pattern to change than it should be” [9]. Similarly, software decay refers may not match the expected runtime execution of the to software that is more difficult to change than it should. Several pattern. Cases such as this are not captured by the current types of software decay have been identified, including code knowledge base of pattern grime. This notion forms the smells, anti-patterns, and design pattern decay [4] [10] [17] [18] basis for this research. Given this, the characterization of [19]. Design pattern decay refers to implementations of design behavioral grime is a gap that needs clear definitions. patterns that gain undesired elements or lose desired elements as 2. Behavioral Grime Taxonomy: To the best knowledge of they evolve. In this sense, the benefits that the pattern offers are the authors, no attempt has been made at categorizing the lost as its design becomes obfuscated. Studies have found that types of behavioral grime in the context of design patterns. design pattern decay negatively impacts testability and 3. Impacts on Quality: Previous studies have identified the understandability of systems [4] [17]. impact of structure-based grime on quality attributes, Previous work in design pattern decay has focused on the showing that testability and maintainability are negatively structure of patterns [8] [14] [15] [17] [18] [19]. These are impacted from structural grime [15] [19]. However, no realized as unwanted or missing artifacts that do not follow the attempt has been made at quantifying the impact of structural specification of the pattern. When these artifacts behavioral grime on these quality attributes and the obscure the implementation of a pattern while still maintaining additional quality attributes featured in the ISO 25010 some of the integrity of the original pattern, they are referred to as software quality specification. design pattern grime. Alternatively, when these artifacts obscure 4. Impacts on Technical Debt: Dale and Izurieta showed an implementation of a pattern to such an extent that the integrity that the injection of modular grime into patterns increases of the pattern is entirely lost, they are referred to as design pattern the technical debt of the pattern [8]. No work has sought rot. Empirical studies have only confirmed the existence of to capture the impact of behavioral grime on technical pattern grime. debt. Further work has classified the types of design pattern grime into 5. Relationships between Behavioral and Structural three disjoint categories: class grime, modular grime, and Grime: Several questions arise that are concerned with the organizational grime [15] [17] [18] [19]. Of these, Schanz and relationships between behavioral and structural grime. For Izurieta expanded the modular grime category, identifying example: How are structural grime and behavioral grime strength, scope, and direction as attributes of modular grime [27]. related? Is the appearance of structural grime causal to the Additionally, Griffith and Izurieta expanded the class grime existence of behavioral grime? Is the reverse true? Are category, identifying strength, scope, and direction/context as there cases where structural grime exists but behavioral attributes of class grime [15]. grime does not? 2.4.1 Design Pattern Specification The process of identifying pattern grime consists of recognizing differences between a pattern instance and a pattern’s specification. A common language used to specify patterns is the Role-Based Meta-Modeling Language (RBML) [22]. RBML is 1 http://www.uml.org/ 34 6. Tool Support: Currently, there is no known tool support research. To what extent should we focus on operationalizing to operationalize behavioral concepts. Implementing a tool behavioral detection and quantification? is an important contribution to the community. 3. Pattern Dataset: The only available dataset of design 7. Predicting Pattern Decay: No research has looked into pattern instances is the Perceron’s dataset [1]. This dataset predicting when a pattern is prone to decaying, or even if only features instances of 10 unique pattern types, all from certain patterns are more prone to decay. Bridges to these the Java programming language. This means that this two research gaps would give valuable insight to research has limited generalizability. Is it necessary or worth developers regarding the implementation of patterns, and the effort to look at more pattern types and/or patterns even when to be aware that a pattern might be near instances from other languages? decaying/rotting. 4. OBJECTIVES 3.2 Operational Gaps A pilot study was performed, in the form of a controlled 4.1 Research Objectives experiment; in which realizations of observer patterns were RG1: Investigate design pattern instances for the purpose of studied. Our dataset consisted of three instances of the observer identifying and characterizing internal and external behavioral pattern that we created ourselves; one instance behaved as grime with respect to proper pattern behavior as defined by the defined, one instance featured Subjects that waited a significant design pattern specification from the perspective of the software amount of time before updating their Observers when their state system in the context of design patterns in open source and changed, and the final instance featured Subjects that did NOT commercial software. update their Observers when their state changed. These three RQ1.1: Does the behavior of a design pattern instance instances exemplify cases where, respectively, (1) a pattern deviate from the expected behavior of that pattern type? behaves properly, (2) a pattern behaves properly but a disharmony exists during its lifetime, and (3) a pattern behaves significantly Rationale: This is the basic question of this research. If it is different from its intended usage. The SonarQube [13] tool, used possible to identify design pattern instances where the actual to estimate Technical Debt, and the inCode tool2, used to identify behavior deviates from expected behavior, then the need to design flaws, were run across the pattern instances. Neither of further explore this phenomenon is apparent. these tools identified a major difference between the three pattern RQ1.2: Do common types of behavioral grime exist within instances, suggesting that state-of-the-art tools used to identify multiple instances of a single pattern type? issues are not capable of detecting problems concerning design Rationale: If common grime types can be identified within a pattern behavior. This experiment highlights the need to explore specific pattern, other instances of that pattern may be this area further. circumspect to the same type of grime. 3.3 Proposed Contributions RQ1.3: Do common types of behavioral grime exist across To address current gaps, the following contributions are proposed: multiple instances of different pattern types? 1. The formal characterization of behavioral grime in Rationale: If common types of behavioral grime exist across design patterns different types of patterns, we will have attained some level 2. The development of taxonomy to classify behavioral of generalizability that applies to a larger set of pattern types. grime RG2: Express the difference between structural and behavioral 3. The development of empirical studies to capture the grime for the purpose of illustrating the importance of studying impacts of grime on TD and quality behavioral grime with respect to design pattern instances from the perspective of design pattern instances in the context of open 4. The identification of patterns that are prone to source and commercial software. behavioral grime RQ2.1: To what extent can patterns have both structural and 5. The creation of a tool that aids in the detection of behavioral grime? behavioral grime Rationale: Consider the grime quadrant in Table 1. Columns 6. The development of a method that allows predictive indicate whether structural grime exists in a pattern, and rows capabilities for recognizing grime indicate whether behavioral grime exists in the same pattern. Current research has identified design patterns with grime, 3.4 IDoESE Feedback Sought but those patterns are constrained by cases A and B. This Advice on the following topics is sought: research needs to be expanded to discover patterns that fall in 1. Overall Scope: Whilst all topics presented in this paper cases C and D. This will illustrate that this work is novel. are interesting and necessary research items, advice on the RQ2.2: Does the current knowledge base of structural grime estimation of work and its feasibility is sought. For the scope instances include cases of behavioral grime? of a doctoral-level degree, is this plan too ambitious? If so, what parts should be prioritized? Rationale: There may be behavioral grime in many of the patterns that exhibit structural grime. 2. Automation: Currently, there is very little automation of these processes. This is a result of exploring a new area of RQ2.3: What is the relationship between behavioral grime and structural grime? 2 https://www.intooitus.com/products/incode 35 patterns tend towards building behavioral grime, then Table 1 -- Grime quadrant of possible grime types. For a given development efforts can be more pro-active in addressing pattern, rows correspond to at least once instance of behavioral pattern evolution. grime existing in the pattern, and columns correspond to at least one RQ4.2: Can behavioral grime be predicted? case of structural grime existing in the pattern. Rationale: This question focuses on the possibility that Structural grime Structural grime underlying mechanisms may exist that allow us to predict does not exist exists when a pattern will accumulate behavioral grime in the future. Behavioral grime Case A Case B does not exist 4.2 Research Metrics Behavioral grime Case C Case D Following the GQM approach [3], several metrics are identified exists that will be used to answer the research questions. M1: Structural Grime Count (SGC) – The total amount of grime Rationale: Intuitively, it appears a relationship exists accumulated in a single pattern realization that is identified from between behavioral and structural grime. Discovering the structural models. This metric will be used to answer RQs 2-4. precise nature of this relationship will help developers M2: Behavioral Grime Count (BGC) -- The total amount of grime understand pattern decay in the future. accumulated in a single pattern realization that is identified from RG3: Quantify the impact of grime in internal and external design behavioral models. This metric will be used to answer RQs 2-4. pattern behavior for the purpose of capturing the effects on system M3: Technical Debt Principal (TDP) – A measure of the cost quality and TD with respect to proper pattern behavior as required to complete a task. This metric will be used to answer defined by the design pattern specification from the perspective of RQ 3. the software system in the context of design patterns in open M4: Technical Debt Interest (TDI) – A measure of differences in source and commercial software. cost required to complete tasks under ideal conditions versus the RQ3.1: To what extent does behavioral grime affect the current condition of the system. This metric will be used to quality attributes of a design pattern? answer RQ 3. Rationale: This research question seeks to quantify the M5: Pattern Quality (PQ) – An aggregated measure of the eight impact behavioral grime has on the quality of the pattern. quality characteristics featured in the ISO 25010 software quality RQ3.2: Is the quality of certain types of behavioral grime specification [16]. Each quality characteristic is further broken worse than other types? down into a number of (sub)-characteristics. This metric reflects an aggregation of the (sub)-characteristics. This metric will be Rationale: This question attempts to identify the forms of used to answer RQ 3. behavioral grime that are worse than others. M6: Probability to Deviate (PD) – The probability that a pattern RQ3.3: To what extent does behavioral grime affect the TD will accumulate grime in the future, given its pattern type, past of a software project? and current SGC, BGC, TDP, TDI, and PQ. This metric will be Rationale: In essence, TD captures the financial impact of used to answer RQ 4. behavioral grime. Understanding this impact is crucial for developers and project managers alike so decisions regarding 4.3 Working Hypotheses release timelines or refactorings can be made. H1: There exist instances of behavioral grime that are not captured by current structural grime models. RQ3.4: Is the TD of certain types of behavioral grime worse than other types? H2: Common forms of behavioral grime exist within the same pattern type. Rationale: This question attempts to identify the forms of behavioral grime that are worse than others. H3: Common forms of behavioral grime exist across different pattern types. RQ3.5: Are the current TD estimation and quality measurement tools capable of capturing behavioral grime? H4: Including behavioral grime in the current grime models will allow the detection of pattern rot. Rationale: Behavioral grime may have an impact on the TD estimate and quality of the pattern. If the current tools are not H5: Quality and TD sufficient in capturing these impacts, then the tools need to H5.1: Behavioral grime has a negative effect on the quality be extended in order to reflect the impact. of the (a) pattern realization, and (b) software system as a RG4: Investigate the evolution of internal and external behavior whole. in design patterns for the purpose of capturing trends of H5.2: Behavioral grime has a negative effect on the TD behavioral grime over time with respect to proper pattern behavior calculation of the (a) pattern realization, and (b) software from the perspective of the software system in the context of system as a whole. pattern in open source and commercial software. H6: Given the pattern type, and past and current measurements of RQ4.1: Can common trends of behavioral grime be captured SGC, BGC, TDP, TDI, and PQ, it is possible to predict whether a as a pattern evolves? pattern will accumulate grime in the future, with a degree of Rationale: This question identifies if patterns are more prone uncertainty. to certain behavioral grime types. If we can predict which 36 5. APPROACH Variance will be measured over all the analysis tools, for each of non-injected and injected patterns. 5.1 Data Collection RQ4.1-2 will be evaluated using an observational study. Patterns Design pattern instances will be collected across a variety of open will be divided by pattern type and assessed for the existence of source and commercial software systems. The Perceron’s dataset grime across their lifetime in terms of project releases. For each features 4500 pattern instances from Java open source software release, a record will exist documenting whether that pattern systems [1]. The patterns featured in this database will be instance has grime or not. Further, an ARIMA analysis will be downloaded to provide an initial set of design pattern instances. performed. This will give an indication into the tendencies of a Additionally, design patterns will be manually extracted from a pattern to collect grime as it ages. commercial software system owned by a local firm with an established relationship. 6. THREATS TO VALIDITY Models of each design pattern instance will be captured using There exist several threats to the validity of this study. Internal UML class diagrams and UML sequence diagrams3. Class validity refers to the ability to recognize a causative relationship diagrams capture the structural elements of the pattern instance, in the study, and not as a result of confounding variables. Internal and sequence diagrams capture the behavioral elements of the validity is threatened because other design defects may exist pattern instance. Additionally, pattern specifications for each alongside grime in a pattern; thus design defects are a pattern type will be captured in UML class and sequence confounding variable in this study. To attempt to remove the diagrams, using RBML and OCL. effect of design defects, we utilize a large number of pattern The PQ, TDI, and TDP of each pattern instance will be calculated. instances in the analysis and block across pattern type. This These metrics will be calculated for both individual pattern mitigates the chance that a design defect will affect the results of instances and the entire software system that the pattern originates the study. from. This data will be stored in a relational database. External validity refers to the ability to generalize from the results of the study. External validity is threatened because of the limited 5.2 Research Approach datasets of design pattern instances. To combat this threat, we Once the data collection process is complete, a variety of case have utilized the Perceron’s dataset, which is the only publically studies and experiments will be used to answer the research available dataset of patterns that features a large number of questions. Juristo and Moreno’s guide on experimentation in instances (over 4500), and pattern instances from a local software engineering will be used to initially construct commercial software firm. Patterns from both these datasets are experiments [20]. implemented in Java, and the Perceron’s dataset features only RQ1.1-3 will be evaluated using a case study, wherein the open source patterns. Therefore, the ability to generalize the taxonomy of design pattern grime will be extended to incorporate results is limited to the population of patterns in this study. behavioral grime types. All pattern instances will be categorized according to their behavioral and structural conformance from the 7. CONCLUSIONS grime quadrant of Table 1. We will manually sort through each We have outlined the work that will result in a doctoral category, identifying design pattern violations. Violations that dissertation in hopes that we can receive feedback on the merit of share similarities (OCL or RBML) will be grouped. this research. Research gaps are presented and studies are RQ2.1-3 will be evaluated using a case study. Conformance designed that fill them. We intend to contribute novel research checking algorithms will be implemented that validate the that strengthens the current state of empirical software structural conformance and behavioral conformance according to engineering. the work done by [21] [28]. All available pattern instances will be This research is in its early stages. Currently, preliminary research categorized into one of the four groups defined in Table 1. A has been performed, for the purpose of illustrating the research binomial regression model will be fitted from the sample in order gaps. This research includes generating pattern instances and to answer RQ2.3. manually injecting grime into them, as described in section 3.2. RQ3.1-5 will be evaluated using a controlled experiment. Patterns Additionally, two potential forms of behavioral grime have been will be blocked according to pattern type and then randomly identified. Next steps call for the analysis of a larger number of selected from the available dataset. Patterns will be evaluated for pattern instances that expand the taxonomy of behavioral grime. TD and quality using a suite of static and dynamic analysis tools, as discussed in section 2. After measurements are recorded, forms 8. REFERENCES of grime will be randomly selected and injected into patterns. [1] Ampatzoglou, A., Michou, O., and Stamelos, I. Building and After injecting, we will re-evaluate the TD and quality mining a repository of design pattern instances: Practical and measurements. To analyze the data, two ANOVA tests will be research benefits, Entertainment Computing, Volume 4, utilized. RQ3.1-4 will be answered by fitting a two mean model, Issue 2, April 2013, Pages 131-142, ISSN 1875-9521, DOI= containing a mean for non-injected patterns and a mean for http://dx.doi.org/10.1016/j.entcom.2012.10.002. injected patterns. That is, the respective TD and quality measurements from all tools that analyzed non-injected patterns [2] Bansiya, J.; Davis, C.G., A hierarchical model for object- will be averaged. Respectively, the same analysis will be done for oriented design quality assessment, Software Engineering, injected patterns. RQ3.5 will be answered by fitting a separate IEEE Transactions on , vol.28, no.1, pp.4,17, Jan 2002 means model; that is, each quality analysis tool will have a mean. [3] Basili, V., Caldiera, G., and Rombach, H. D. 1994. The goal question metric approach. Encyclopedia of Software Engineering. 2, 528-532. DOI=http://dx.doi.org/ 3 http://www.uml.org/ 10.1002/0471028959.sof142 37 [4] Bieman, J.M., and Wang, H. 2006. Design pattern coupling, Colorado State University, Fort Collins, CO, USA. change proneness, and change coupling: A pilot study. Advisor(s) James Bieman. AAI3385139. Technical Report. Colorado State University. [19] Izurieta, C., Bieman, J. 2013. A multiple case study of design [5] Brown, W. H., Malveau, R. C., McCornnick III, H. W., and pattern decay, grime, and rot in evolving software systems. J. Mowbray, T. J. 1998. Antipatterns: Refactoring Software, Software Quality. 21, 2 (Jun. 2013), 289-323. DOI= Architectures, and Projects in Crisis. Wiley & Sons, NY. http://dx.doi.org/10.1007/s11219-012-9175-x. [6] Curtis, B., Sappidi, J., and Szynkarski, A. Estimating the [20] Juristo, N., Moreno, A.M. 2013. Basics of Software Principal of an Application's Technical Debt, IEEE Software, Engineering Experimentation. Springer, US. vol. 29, no. 6, pp. 34-42, Nov.-Dec., 2012 DOI= [21] Kim, D. 2004. A Meta-Modeling Approach to Specifying http://doi.ieeecomputersociety.org/10.1109/MS.2012.156 Patterns, Ph.D. Dissertation. Colorado State University, Fort [7] Cunningham, W. 1992. The WyCash portfolio management Collins, CO, USA. Advisor(s) Robert France. system. SIGPLAN OOPS Mess. 4, 2 (December 1992), 29- [22] Kim, D. The Role-Based Metamodeling Language for 30. DOI=http://doi.acm.org/10.1145/157710.157715 Specifying Design Patterns. In Toufik Taibi, editor, Design [8] Dale, M.R., and Izurieta, C. 2014. Impacts of design pattern Pattern Formalization Techniques. Idea Group Inc., 2006. decay on system quality. In Proceedings of the 8th [23] Letouzey, J., Ilkiewicz, M., Managing Technical Debt with ACM/IEEE International Symposium on Empirical Software the SQALE Method, IEEE Software, vol. 29, no. 6, pp. 44- Engineering and Measurement (ESEM '14). ACM, New 51, Nov.-Dec., 2012. York, NY, USA, Article 37, 4 pages. DOI=http://doi.acm.org/10.1145/2652524.2652560 [24] Marinescu, R., Assessing technical debt by identifying design flaws in software systems, IBM Journal of Research [9] Eick, S.G., Graves, T.L., Karr, A.F., Marron, J.S., and and Development , vol.56, no.5, pp.9:1,9:13, Sept.-Oct. 2012 Mockus, A. Does code decay? Assessing the evidence from DOI=http://dx.doi.org/10.1147/JRD.2012.2204512 change management data, Software Engineering, IEEE Transactions on, vol.27, no.1, pp.1-12, Jan 2001. [25] Nugroho, A., Visser, J., and Kuipers, K. 2011. An empirical model of technical debt and interest. In Proceedings of the [10] Fowler, M., Beck, K., Brant, J., and Opdyke, W. 1999. 2nd Workshop on Managing Technical Debt (MTD '11). Refactoring: Improving the Design of Existing Code. ACM, New York, NY, USA, 1-8. Addison-Wesley Longman, Inc., Reading, MA. DOI=http://doi.acm.org/10.1145/1985362.1985364 [11] France, R.B., Kim, Dae-Kyoo, Ghosh, S., and Song, E. 2004. [26] Sangal, N., Jordan, E., Sinha, V., and Jackson, D. 2005. A UML-based pattern specification technique, Software Using dependency models to manage complex software Engineering, IEEE Transactions on, vol.30, no.3, pp.193, architecture. In Proceedings of the 20th annual ACM 206. SIGPLAN conference on Object-oriented programming, DOI=http://dx.doi.org/10.1109/TSE.2004.1271174 systems, languages, and applications (OOPSLA '05). ACM, [12] Gamma, E., Helm, R., Johnson, R., and Vlissides, J. Design New York, NY, USA, 167-176. Patterns: Elements of Reusable Object-Oriented Software. DOI=http://doi.acm.org/10.1145/1094811.1094824 Addison-Wesley, 1994. [27] Schanz, T., and Izurieta, C. 2010. Object oriented design [13] Gaudin, O. Evaluate your technical debt with Sonar, Sonar, pattern decay: a taxonomy. In Proceedings of the 2010 ACM- Jun, 2009. IEEE International Symposium on Empirical Software [14] Griffith, I., and Izurieta, C. 2013. Design Pattern Decay: An Engineering and Measurement (ESEM '10). ACM, New Extended Taxonomy and Empirical Study of Grime and its York, NY, USA, Article 7, 8 pages. Impact on Design Pattern Evolution. In Proceedings of the DOI=http://doi.acm.org/10.1145/1852786.1852796 11th ACM/IEEE International Doctoral Symposium on [28] Strasser, S., Frederickson, C., Fenger, K., and Izurieta, C. Empirical Software Engineering and Measurements, USA 2011. An automated software tool for validating design [15] Griffith, I., and Izurieta, C. 2014. Design pattern decay: the patterns. In Proceedings of the of ISCA 24th International case for class grime. In Proceedings of the 8th ACM/IEEE Conference on Computer Applications in Industry and International Symposium on Empirical Software Engineering (HI, USA, November 16-18). CAINE'11. Engineering and Measurement (ESEM '14). ACM, New [29] Tom, E., Aurum, A., and Vidgen, R. 2013. An exploration of York, NY, USA, Article 39, 4 pages. technical debt. J. Syst. and Softw. 86, 6 (Jun. 2013), 1498- DOI=http://doi.acm.org/10.1145/2652524.2652570 1516. DOI=http://dx.doi.org/10.1016/j.jss.2012.12.052. [16] ISO/IEC 25010: Systems and software engineering. Systems [30] Wong, S., Cai, Y., Kim, M., and Dalton, M. 2011. Detecting and Software Quality Requirements and Evaluation software modularity violations. In Proceedings of the 33rd (SQuaRE). System and software quality models, 2011. International Conference on Software Engineering [17] Izurieta, C., and Bieman, J. 2007. How software designs (Honolulu, HI, USA, May 21-28). ICSE’11, 411-420. DOI= decay: A pilot study of pattern evolution. In Proceedings of http://doi.acm.org/10.1145/1985793.1985850 the First Symposium on Empirical Software Engineering and [31] Wagner, S., Lochmann, K., Heinemann, L., Kläs, M., Measurement (Madrid, Spain, 2007). ESEM 2007. 449-451. Trendowicz, A., Plösch, R., Seidl, A., Goeb, A., and Streit, J. DOI= http://dx.doi.org/10.1109/ESEM.2007.55. 2012. The quamoco product quality modelling and [18] Izurieta, C. 2009. Decay and Grime Buildup in Evolving assessment approach. In Proceedings of the 34th Object Oriented Design Patterns. Ph.D. Dissertation. International Conference on Software Engineering (ICSE '12). IEEE Press, Piscataway, NJ, USA, 1133-1142. 38