=Paper=
{{Paper
|id=Vol-1469/paper6
|storemode=property
|title=A Research Plan to Characterize, Evaluate, and Predict the Impacts of Behavioral Decay in Design Patterns
|pdfUrl=https://ceur-ws.org/Vol-1469/paper6.pdf
|volume=Vol-1469
}}
==A Research Plan to Characterize, Evaluate, and Predict the Impacts of Behavioral Decay in Design Patterns==
https://ceur-ws.org/Vol-1469/paper6.pdf
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