=Paper=
{{Paper
|id=Vol-2510/sattose2019_paper_5
|storemode=property
|title=Structural and Behavioral Taxonomies of Design Pattern Grime Evolution
|pdfUrl=https://ceur-ws.org/Vol-2510/sattose2019_paper_5.pdf
|volume=Vol-2510
|authors=Clemente Izurieta,Derek Reimanis,Isaac Griffith,Travis Schan
|dblpUrl=https://dblp.org/rec/conf/sattose/IzurietaRGS19
}}
==Structural and Behavioral Taxonomies of Design Pattern Grime Evolution==
https://ceur-ws.org/Vol-2510/sattose2019_paper_5.pdf
Structural and Behavioral Taxonomies of Design Pattern
Grime
Clemente Izurieta Derek Reimanis
Montana State University Montana State University
Bozeman, MT 59717 Bozeman, MT 59717
clemente.izurieta@montana.edu derek.reimanis@msu.montana.edu
Isaac Griffith Travis Schanz
Idaho State University Fast Enterprises LLC
Pocatello, ID 83209 South Burlington, VT 05403
grifisaa@isu.edu tschanz@gentax.com
systems evolve however; the pressures to release early,
the experience and turn over of software engineers, and
Abstract the complexities of designs all contribute to the decay
of software systems. The measurement of such de-
Design Patterns represent the encapsulation cay is complex and our contribution has focused on
of good design experiences and agreed upon design patterns. We can think of design patterns as
solutions to common problems; however, as micro-architectures that are embedded in larger sys-
they evolve, they tend to develop grime –non- tems. Because their structure and behavior can be de-
pattern related design components. Grime is scribed by meta-modeling languages such as the Role
a form of software decay that obfuscates the Based Modeling Language (RBML) [Fra02], this al-
realization of a pattern and has decisively neg- lows us to compare realizations of patterns extracted
ative consequences on quality attributes of the from source code against their intended architecture;
pattern and consequently its embedding soft- thus we have an ability to measure their drift as the
ware. Grime comes in structural and behav- pattern realization evolves over time.
ioral forms. In this paper we synthesize a se-
ries of grime classifications that today form a The drift of a design pattern from its original in-
general taxonomy. The taxonomy represents tent can be described as rot or grime [Izu09] [Izu07].
a validated and peer reviewed accumulation of Design pattern rot is the breakdown of a design pat-
knowledge that is continually evolving. tern such that a critical element in the pattern ceases
to exist. Thus, a realization of a pattern that expe-
1 Introduction riences rot is no longer a representation of its micro-
architecture. Rot is difficult to find because as the re-
The evolution of design patterns represents the evolu- alization evolves, it becomes harder to identify. Design
tion of concepts that capture domain experience. Pat- pattern grime is the buildup of unrelated artifacts in
terns were introduced and adopted widely by the ob- classes that play roles in a design pattern realization.
ject oriented community, and this can be traced to a These artifacts do not contribute to the intended role
marquee event when the Gang of Four book [Gam95] of a design pattern. Over time the pattern realization
was adopted by academics and practitioners alike. As becomes hidden from practitioners.
Copyright c 2019 for this paper by its authors. Use permitted The manuscript described herein provides a detailed
under Creative Commons License Attribution 4.0 International
(CC BY 4.0)
description of a taxonomy for design pattern grime.
In: Anne Etien (eds.): Proceedings of the 12th Seminar on Ad-
Each subsection describes one aspect of the taxonomy.
vanced Techniques Tools for Software Evolution, Bolzano, Italy, At the highest level we differentiate between structural
July 8-10 2019, published at http://ceur-ws.org and behavioral categories.
1
2 Related Work sign patterns. Kim et al. [Kim04] and France et al.
[Fra02] introduced the Role-Based Metamodeling Lan-
2.1 Software Evolution
guage (RBML) for characterizing generic and domain-
Although a comprehensive summation of software evo- specific design patterns. RBML is based upon UML
lution is beyond the scope of this paper, it is important and uses the same syntax as UML. It consists of a
to highlight key contributions that influenced the de- number of behavioral and structural diagrams with
velopment of this taxonomy. each one describing different parts of the design pat-
The earliest contributions and seminal work can be tern. A design pattern specification consists of two
attributed to Lehman’s revised laws of software evo- sub-specifications, the Structural Pattern Specification
lution [Leh97]. Although controversial for their sub- (SPS) and the Interaction Pattern Specification (IPS).
jectivity, Lehman established a platform from which An SPS characterizes the structural elements of a pat-
operational approaches to software evolution measure- tern, including the class members, attributes, opera-
ments could be derived. The common trends proposed tion signatures, and relationships. An IPS character-
by the laws in software growth required validation that izes the behavioral elements of a pattern, and details
have been the subject of many studies. the flow of information that occurs as a design pattern
Studies associated with software aging that influ- is in operation, i.e., at program run-time. SPSes are
enced this work include the early insights of Parnas analogous to UML class diagrams, whereas IPSes are
[Par94]; which uses an analogy between software sys- analogous to UML sequence diagrams. Both diagrams
tems and medical systems to describe software aging. exist at a meta-level that describes design specifica-
He uses medical terms, which equate refactoring to tions, which is referred to as the M2 level [Fra02].
major surgery. Parnas also applies the notion of sec-
ond opinions and describes the cost associated with 3 Taxonomy
preventative measures. Eick et al. [Eic01] use a num-
ber of generic code decay indices (CDIs) to analyze We divide the taxonomy of design pattern grime
the change history of a telephone switching system to into two major categories: structural and behavioral.
investigate decay. Structural refers to the changes observed via static
Recent work in design pattern grime evolution has analysis of source code or the designs; which are ex-
been performed by Feitosa et al. [Fei17]. They found tracted into UML [UML97] class diagrams. UML class
that design pattern grime has a tendency to accumu- diagrams of design pattern realizations can be mea-
late linearly, suggesting the quality of a pattern wors- sured for compliance against the structural RBML
ens as the grime of that pattern increases over subse- meta-model that characterizes (potentially) an infinite
quent releases. number of UML models of design patterns. Behavioral
It is also important to note that although evolu- refers to the deviations observed from a flow of infor-
tion studies of design patterns continue to grow, little mation perspective that captures the operational side
research has been performed outside the open source of a design pattern at run time. UML sequence dia-
community. Further, the evolution of error propaga- grams can also be characterized by RBML, and we can
tion and uncertainty of measurements, although ad- measure an extracted UML sequence diagram of a de-
dressed by [Izu13] remains an under studied compo- sign pattern realization against its RBML meta-model.
nent. Figure 1 shows the highest level of the hierarchy.
Taxonomies represent a natural progression of ev-
idence collected from multiple empirical studies as-
sociated with the evolution of design patterns, and
is essential. ”A taxonomy promotes the classifica-
tion of grime into ordered groups that are disjoint
and complete while preserving natural relationships be-
tween categories” [Sch10]. The classification, descrip-
tion and naming of various forms of grime as appli- Figure 1: Design Pattern Grime Taxonomy
cable to each individual design pattern have evolved
since circa 2010.
The following subsections describe structural and
behavioral grime respectively. The description repre-
2.2 Role Based Modeling Language
sents an abridged high level overview. Formal math-
RBML is a visually oriented language defined in terms ematical descriptions of each grime classification are
of a specialization of the UML metamodel that is used available for modular grime [Sch10]. A full definition
to verify and specify generic or domain specific de- in currently under development.
2
3.1 Structural Grime ing the properties of class cohesion. Cohesion [Bri98]
is used to describe the integrity of the construction of
Structural grime is classified into three main cate-
a class. High cohesion in a class indicates close align-
gories: modular, class, and organizational. Modular
ment of the internal components towards a common
grime is indicated by increases in the coupling of the
goal. In design pattern realizations, classes should
pattern as a whole, by tracking the number of relation-
have distinct responsibilities and if implemented cor-
ships (generalizations, realizations, associations, de-
rectly, then the specification will have high cohesion.
pendencies) pattern classes have with external classes.
Thus, cohesion provides a basis to determine whether a
Class grime is associated with the classes that play a
design pattern realization has been afflicted with class
role in the design pattern and grime is indicated by
grime. Figure 4 shows the hierarchy of class grime.
increases in the number of ancestors of the class, the
Strength is indicated by the method in which attributes
number of public attributes, and lack of cohesion. Or-
are locally accessed by the methods of a class. The
ganizational grime refers to the distribution and or-
method of access can be either direct (attributes are
ganization of the files and namespaces that make up
directly accessed by methods) or indirect (attribute ac-
a pattern. Figure 2 shows the first level of structural
cess through the use of an accessor/mutator methods).
grime.
Direct attribute access provides a stronger and quicker
but brittle relationship between a method and an at-
tribute. Indirect attribute access implies a more flex-
ible and weaker relationship between the method and
attribute, but one which is more amenable to refac-
toring because it is also considered good use of design.
Scope can either be internal or external. Internal scope
refers to attribute access by local methods. External
Figure 2: Structural Grime scope refers to attribute access by at least one local
method that is not defined by the pattern specifica-
tion. Finally, Direction (or Context) refers to the types
3.1.1 Modular Grime of relationships used by surrogate metrics to measure
cohesion. The majority of cohesion metrics take one
Modular grime was further developed and validated of two perspectives: single-method use or method pair
by [Sch10] and strength, scope and direction were used use of attributes [Bri98]. Two metrics capture this di-
to classify it at its highest level. Figure 3 shows the mension: Tight Class Cohesion (TCC) [Bie95] which
hierarchy where the left most column displays the di- measures the cohesion of a class by looking at pairs
mensions and classification. of methods with attributes in common, and the Ratio
Coupling can be classified on an ordinal scale ac- of Cohesive Interactions (RCI) [Bri93] metric which
cording to strength [Bie04]. Strength is determined measures the cohesion of a class by looking at how
by the difficulty of removing the coupling relationship. individual methods use attributes.
Persistent and temporary coupling are the most com-
mon forms in object oriented systems. The Strength
3.1.3 Organizational Grime
of the relationship can be measured by afferent (Ca)
and efferent (Ce) coupling to refer to the direction of Organizational grime was developed by Griffith
a coupling relationship [Mar94]. The afferent coupling [Gri19]. Figure 5 depicts the classification according
or fan-in is the count of in-bound relationships and the to this taxonomy. Organizational grime refers to the
efferent coupling or fan-out is the count of out-bound distribution and organization of the files, packages and
relationships of a set of classes. Finally, the Scope namespaces that make up a design pattern. The de-
refers to the boundary of a coupling relationship and velopment of the organizational grime hierarchy comes
can be either internal or external. A class belonging from the following design principles [Mar03]:
to a design pattern develops a relationship with exter-
nal scope if another class (not in the design pattern) is • The Acyclic Dependencies Principle (ADP): De-
coupled with the former. A relationship has internal pendencies between packages should not form cy-
scope if the coupling involves two classes belonging to cles
the same realization of a design pattern.
• The Stable Dependencies Principle (SDP): De-
3.1.2 Class Grime pend in the direction of stability
Class grime was identified by Griffith and Izurieta • The Stable Abstractions Principle (SAP): Ab-
[Gri14]. The class grime category was extended us- stractness should increase with stability
3
Figure 3: Modular Structural Grime
Figure 4: Class Structural Grime
4
• The Common Closure Principle (CCP): Classes in not a design pattern is behaving as intended. A pat-
a package should be closed to the same kinds of tern instance may have no structural grime, but the
changes runtime execution of the pattern may not match the
expected runtime execution of the pattern.” Reimanis
• The Common Reuse Principle (CRP): Classes in and Izurieta [Rei16] identify two specific types of er-
the same package should be reused together rant behaviors: Excessive Actions and Improper Order
of Sequences. Both of these behaviors were applied to
These principles describe the coupling between
the modular grime taxonomy [Rei19], to help gener-
packages and the cohesion within a package. Using the
ate a taxonomy of behavioral grime, which is shown in
properties of package coupling and cohesion we have
figure 6.
divided package grime into twelve specific subtypes.
The dimensions of the behavioral grime taxonomy
Package coupling is used to develop the modular
are as follows: Strength refers to a relationship be-
subtype of organizational grime. We consider three
tween two UML members where Persistent Strength
properties of coupling between packages. The first is
refers to a UML association while Temporary Strength
the Strength, which can be either Persistent or Tempo-
refers to a UML use-dependency. Scope refers to the
rary. Persistent couplings are those created by inher-
context of the relationship between two UML mem-
itance, realization, and associations. Temporary cou-
bers; Internal Scope refers to a relationship between
plings include use dependencies. Scope can be either
two pattern members, and External Scope refers to
Internal or External. Internal couplings are those that
a relationship between one pattern member and one
are caused by classes within the same pattern realiza-
non-pattern member. Direction refers to the direc-
tion but spread across packages. External couplings
tion of the relationships. Afferent Direction refers to
are relationships between packages that are caused by
fan-in while Efferent Direction refers to a fan-out rela-
external classes interacting with pattern classes across
tionship. The Classification row at the bottom of the
packages. The final property is Direction. This dimen-
figure refers to the acronym that captures the type of
sion refers to how the coupling affects cyclic dependen-
behavioral grime; for example, the TIO classification
cies between packages; which we label as cyclical, and
is an acronym for Temporary-Internal-Order grime.
the flow of stability between packages; which we la-
The dimensions and corresponding levels of the be-
bel as unstable. When we consider whether the new
havioral grime taxonomy closely mirror the modular
dependency causes cycles between packages we are in
grime taxonomy dimensions and levels because there
the cyclical context, and when we consider the flow
is an inherent relationship between modular and be-
of dependencies towards stability, then we are in the
havioral grime. Modular grime dictates the unwanted
unstable context. Together these concepts are used to
presence of relationships between two UML members,
form the modular branch of organizational grime.
which includes all combinations of pattern members
Package cohesion is used to develop the package
and non-pattern members. Because of this, modu-
subtype of organizational grime. We consider only the
lar grime provides a high-level constraint on undesired
Scope and Context dimensions. Scope can be either In-
pattern behaviors. However, the behavioral grime tax-
ternal or External, both referring to the addition of a
onomy does not mirror the modular grime taxonomy
new class or type to a package. If the new class or type
identically; specifically, the External-Efferent levels of
is also a member of the pattern under consideration,
Order Behavioral grime are missing. This is because
then its scope is internal, otherwise it is external. Con-
those levels are nonsensical for Order grime. External-
text takes the form of either Closure or Reuse. Closure
Efferent Order grime corresponds to a behavior from
indicates whether a new class or type fits within the
a pattern member to a non-pattern member that is
package by being closed to similar changes as the other
out of order. Proper pattern order is dictated by pat-
classes. Reuse indicates that we are concerned with
tern members calling each other in the correct order,
how well a class integrates into its containing package
and this definition does not include non-pattern mem-
based on how tightly it couples with the remaining
bers. Thus, the External-Efferent level of the behav-
classes. Together these concepts are used to form the
ioral grime taxonomy is missing.
package branch of organizational grime.
3.2 Behavioral Grime 4 Operationalization of Grime Evolu-
tion
Behavioral grime refers to the behavioral elements em-
bedded in a design pattern. Behavior is encapsulated In order to validate the taxonomy, we submit one oper-
in the constructors and the operations of the design ationalization approach. Tracking drift of design pat-
pattern. Reimanis and Izurieta [Rei15] state that tern realizations in-situ from their intended design re-
”structural grime is incapable of capturing whether or quires multiple steps including detection, compliance
5
Figure 5: Organization Structural Grime
Figure 6: Behavioral grime taxonomy. Dimensions of behavioral grime are listed on the left, and corresponding
characterizations are shown in the taxonomy tree
.
6
checking, and tracking drift over multiple releases. lishing structural conformance via the algorithm pre-
Detection is a difficult problem that has been tack- sented by Kim and Shen [Kim08]. If structural confor-
led by many researchers. We have leveraged many mance is not reached, behavioral conformance cannot
tools to help with the detection of the pattern real- be reached. After structural conformance has been
izations we track. They range from the simplest tools established, the algorithm evaluates the presence of
[DP1] that traverse your code and provide hints as expected behaviors, which we refer to as stack-calls,
to the location of potential realizations, to the more mapping expected stack-calls to their respective mem-
involved tools that build internal representations of ber in the RBML behavioral specification. A pat-
graphs where nodes represent software classes and tern realization is said to conform to a RBML spec-
edges represent different types of relationships between ification when all members of the RBML specification
nodes [Tsa06]. have at least one mapping from the pattern realiza-
Once a design pattern realization is identified in the tion. Though the pattern realization may have stack-
source code, we extract a UML class and a UML se- calls that do not have a mapping to the respective
quence diagram from the realization. These diagrams behavioral specification; such stack-calls are an indi-
are used as representations of individual design pat- cation of a pattern’s flexibility. A pattern’s character-
tern realizations that can be compared against the ization allows for full behavioral conformance even if
RBML characterization of the pattern to check for other non-necessary stack-calls are included. However,
compliance. The RBML represents an abstraction of these non-necessary stack-calls may constitute behav-
a pattern solution that can be thought of as the or- ioral grime if they negatively impact the qualities of
acle for the pattern. The realization pattern’s corre- the design pattern. Therefore, after evaluating behav-
sponding UML diagrams can be compared against the ioral conformance, we evaluate the order and repeti-
pattern’s RBML to provide a quantifiable way of mea- tion of all stack-calls that are mapped to at least one
suring drift, and thus, grime. RBML behavioral member. If a stack-call appears out
Implementations of design pattern realizations in a of the expected order or is repeated unnecessarily, it is
software project exists at the design level, which is labelled as behavioral grime, the specific form of which
referred to as the M1 level. The process of checking is found based on its UML properties.
conformance for a pattern instance entails mapping
the patterns members that exist at its M1 level imple- 5 Tool Support
mentation to its corresponding pattern roles, captured
To exemplify the conformance checking and evolution
with an SPS and IPS, at its respective M2 level pat-
of distinct modular grime types we describe two tools
tern definition. Figure 7 exemplifies the process of con-
developed by the Software Engineering Laboratories
formance checking from design pattern realizations to
(SEL) at Montana State University.
their corresponding characterizations in RBML. The
Using the algorithm described in section 4, Strasser
diagram at the top depicts the structural conformance
et al. [Str11] developed a scoring function that can be
of a simple Observer pattern realization extracted from
visualized using a tool 1 that automatically compares
source code against its RBML SPS, and the picture
the structural RBML SPS against UML diagrams ex-
at the bottom depicts the corresponding conformance
tracted from source code that represent design pattern
check of the behavior from a UML sequence diagram
realizations. The tool reports whether or not the dia-
against the RBML IPS.
grams match, the score, if there were any errors, and
Conformance checking of the algorithm depicted
displays the two diagrams. Figure 8 is a screen shot
in figure 7 has been implemented by Strasser et al.
that show how a realization of a Visitor pattern (bot-
[Str11]. To compare an RBML specification and a
tom of the screen) is checked for conformance against
UML diagram, the authors use a divide-and-conquer
its RBML.
algorithm developed by Kim and Shen [Kim08], and
On the Diagram Selection section of the pane, the
works by breaking the RBML and UML diagrams into
user has access to drop down menus for choosing the
blocks, which are defined as any two classes or classi-
RBML and UML diagrams to compare. In the middle
fiers (classes and interfaces in UML) which have a re-
panes RBML/UML Diagram Image, both diagrams
lationship between them. Three kinds of relationships
are displayed (the RBML diagram is displayed on top
define three kinds of block types: association blocks,
and the UML diagram is displayed immediately be-
generalization blocks, and dependency blocks. The al-
low). The results of running the algorithm (c.f. section
gorithm implemented by Strasser et al. only focuses
4) are displayed on the right hand side screen. Errors
on the structural components.
are labeled and displayed in the Error Log pane. The
An algorithm for asserting behavioral conformance
tool reports problems that the algorithm found, such
was designed by Kim [Kim03] and later formalized by
Lu and Kim [Lu11]. This algorithm begins by estab- 1 https://code.google.com/archive/p/rbml-uml-visualizer/
7
Figure 7: RBML Compliance checking of design pattern realizations
8
Figure 8: RBML tool to perform structural compliance checking of design pattern realizations
as mismatches between UML and RBML artifacts. Di-
rectly below in the box labeled Pass or Fail, the tool
reports whether there was a UML diagram found that
conforms to the RBML diagram. Immediately to the
right is the score calculated using the scoring equation
described above.
To visualize the evolution of design patterns Schanz
and Izurieta [Sch10] developed a prototype to visual-
ize grime. It allows the user control over the level of
importance (i.e. a weight) for a desired pattern grime.
These controls provide flexibility when exploring the
evolution of a design pattern realization over its his-
tory. Figure 9 shows the evolution of pattern grime for Figure 10: Observer grime growth
a realization of the Singleton pattern where all forms
of grime are given equal weights. 6 Motivation and Contribution Discus-
sion
Although the usage of design patterns is promoted as
being consistent with good design principles that help
with maintainability and extensibility of software sys-
tems; practitioners often indicate that design patterns
do not evolve as intended. Early results by the au-
thors indicated that this was consistent with practi-
tioner’s observations, yet the decay observed in specific
instances of design patterns could not be categorized
due to a lack of taxonomy. To better understand if
specific types of grime rot were more likely to occur
Figure 9: Singleton grime growth than others, we set out to investigate how grime oc-
curs and to categorize the different types. This allows
Figure 10 shows the evolution of a realization of the researchers to compare and contrast the types of grime
Observer pattern where the user is mostly interested that are more likely to occur, and which design pat-
in the evolution of Permanent External Afferent Grime terns are more succeptible to such grime.
(PEAG), and with a 0.5 weight, also shows slight inter- Although the obfuscation of design pattern in-
est in Temporary External Afferent Grime (TEAG). stances is mainly due to couplings that elements of
9
the pattern develop over time, we also found that the 8 Future Work
strength, direction and scope of couplings help refine
Although significant work had led to this point, we
the taxonomy. We found that not all couplings are
continue to develop and refine the mathematical defi-
equal in terms of the contribution to decay. Further,
nitions of each form of grime (outside the scope of this
we found that cohesion of classes that are part of a
manuscript). Further, taxonomy is never complete,
design pattern played an important role in contribut-
and we suspect rare forms of change exist that may not
ing to decay. Finally, the behavioral aspects of grime
be fully captured by this taxonomy yet. Continued ef-
required that we adjust the dimensions to fit the dy-
forts to define, calibrate, and empirically validate each
namic (i.e. runtime) definitions.
form of grime are on-going and we expect to expand
Over the last ten years, our investigations have in-
the research to not only include open source, but also
crementally added to the formation of the taxonomy
commercial systems.
presented herein. Further, the aggregation of each as-
pect of the taxonomy into a cohesive hierarchy repre-
sents a contribution to the body of knowledge in this
References
space. [Gam95] Gamma, E., Helm, R., Johnson, R., Vlis-
To aid in comparing how different types of grime sides, J. Design Patterns: Elements
evolve over time, we developed visualization tech- of Reusable Object Oriented Software.
niques and tools that allow users to focus on specific Addison-Wesley, Reading MA, 1995.
types of grime observed. Specifically, the tools allow
users to parameterize weights (i.e., coefficients) asso- [Fra02] France,R.,Kim,D.,Song,E.,Ghosh,S.
ciated with variables representing different types of Metarole-basedmodelinglanguage(rbml)
grime from the taxonomy. specification v1. 0. Tech. rep., 0. Tech-
nical Report 02-106. Computer Science
Department, 2002.
7 Conclusion
[Izu09] Izurieta C. Decay and grime buildup in evolv-
Research provides ample evidence that suggests that
ing object oriented design patterns Colorado
as design patterns age, the realizations of patterns re-
State University, 2009.
main and grime builds up. Such grime buildup can
have negative and adverse consequences on many qual- [Izu07] Izurieta C., Bieman J. How Software De-
ities of designs. Although the design pattern realiza- signs Decay: A Pilot Study of Pattern Evolu-
tions seem to survive as systems evolve, they become tion. First International Symposium in Em-
obfuscated, thus making them difficult to detect, main- pirical Software Engineering and Measure-
tain and refactor –”the original realization of design ment, ESEM’07, Madrid, Spain, 2007.
patterns remain, and the decay is measured around the
grime that grows around the pattern realization over a [Leh97] Lehman M.M., Laws of Software Evolu-
period of time.” tion Revisited. Proc of the 1996 European
These studies helped provide the necessary moti- Workshop on Software Process Technology
vation to investigate the specifics of grime buildup in (EWSPT). France, 1996 Lecture Notes in
design pattern evolution; which lent itself to the devel- Computer Science 1149, pp. 108-124, 1997.
opment of a taxonomy. Our motivation to explore the
taxonomy across three different dimensions, namely [Par94] Parnas D.L., Software Aging. Invited Ple-
Strength, Scope, and Direction is driven by the metrics nary Talk. 16th International Conference
that can be used as surrogates to capture and quantify ICSE 1994, pp. 279-287, May 1994.
change. Although other choices are possible, this ap- [Eic01] Eick, S.G., Graves T.L., Karr A.F., Marron
proach facilitated the validation of the proposed work J.S., Mockus A., Does Code Decay? Assess-
through empirical analysis in open systems. ing the Evidence from Change Management
Two major classifications of design pattern grime Data. IEEE Transactions on Software Engi-
were found: structural, and behavioral. Each classifi- neering, 27(1):1-12, 2001.
cation is then subdivided into further sub categories.
For each category we developed synthetic examples to [Fei17] Feitosa, D., Avgeriou, P., Ampatzoglou, A.,
help calibrate a formal definition represented in the Nakagawa, E.Y. The evolution of design
RBML meta-modeling language. The evolution of in- pattern grime: An industrial case study.
dividual pattern realization’s grime change can now Intl. Conference on Product-Focused Soft-
be measured against its formal characterization and ware Process Improvement, pp. 165-181,
tracked for each pattern as the system evolves. Springer, 2017.
10
[Izu13] Izurieta C., Griffith I., Reimanis D., Luhr [Rei15] Reimanis D., Izurieta C. A Research Plan to
R. On the Uncertainty of Technical Debt Characterize, Evaluate and Predict the Im-
Measurements. IEEE ICISA 2013 Intl. Con- pacts of Behavioral Decay in Design Pat-
ference on Information Science and Applica- terns. IEEE, ACM IDoESE, 13th Inter-
tions, Pattaya, Thailand, June 24-26, 2013. national Doctoral Symposium on Empirical
Software Engineering, Beijing, China 2015.
[UML97] OMG The Object Management Group OMG
2.0 http://www.omg.org [Rei16] Reimanis D., Izurieta C. Towards assessing
the technical debt of undesired software be-
[Sch10] Schanz T., Izurieta C. Object Oriented De- haviors in design patterns.. IEEE 8th Inter-
sign Pattern Decay: A Taxonomy. 4th Inter- national Workshop on Managing Technical
national ACM-IEEE Symposium on Empiri- Debt (MTD), pp. 24-27, Raleigh, N.C. 2016.
cal Software Engineering and Measurement,
ESEM’10. Bolzano, Italy, 2010. [Rei19] Reimanis D., Izurieta C. Behavioral Evo-
lution of Design Patterns: Understanding
[Gri14] Griffith I., Izurieta C. Design Pattern De- Software Reuse through the Evolution of Pat-
cay: The Case for Class Grime. 8th Inter- tern Behavior.. 18th International Confer-
national ACM-IEEE Symposium on Empiri- ence on Software and Systems Reuse. ICSR,
cal Software Engineering and Measurement, Cincinnati, OH. 2019.
ESEM’14. Torino, Italy, 2014.
[DP1] Softpedia Design Pattern Finder
[Bri98] Briand, L.C., Daly, J.W., and Wust, J.K. A https://www.softpedia.com/ Accessed:
unified framework for cohesion measurement 04, 2019.
in object-oriented systems. Empirical Soft-
ware Engineering 3, 1, 65-117. 1998. [Tsa06] Tsantalis, N., Chatzigeorgiou, A.,
Stephanides, G., Halkidis, S.T. Design
[Bie04] Bieman J., Wang H. Evaluating the Strength pat- tern detection using similarity scoring
and Impact of Design Pattern Coupling. Sub- IEEE transactions on software engineering
mitted manuscript IEEE Transactions on 32(11), pp. 896-909, 2006.
Software Engineering, 2004.
[Kim04] D.-K. Kim, R. France, and S. Ghosh A uml-
[Bri93] Briand, L., Morasca, S., and Basili, V. Mea- based language for specifying domain-specific
suring and assessing maintainability at the patterns. Journal of Visual Languages &
end of high level design. In Proceedings of Computing, vol. 15, no. 3-4, pp. 265-289,
IEEE Conference on Software Maintenance. 2004.
Montreal, Canada, pp. 88-87, 1993.
[Str11] Strasser S., Frederickson C., Fenger K.,
[Mar94] Martin R. OO Design Quality Metrics- Izurieta C. An Automated Software Tool for
An Analysis of Dependencies. Proc. Work- Validating Design Patterns. ISCA 24th In-
shop Pragmatic and Theoretical Directions ternational Conference on Computer Appli-
in Object-Oriented Software Metrics, OOP- cations in Industry and Engineering, CAINE
SLA, 1994. ’11, Honolulu, HI, November 2011.
[Bie95] Bieman, J.M. and Kang, B.K Cohesion and [Kim08] D.-K. Kim and W. Shen Evaluating pattern
reuse in an object-oriented system. Proceed- conformance of uml models: a divide-and-
ings of the ACM 2nd Symposium on Soft- conquer approach and case studies. Software
ware Reusability, WA, USA, New York, NY. Quality Control, vol. 16, pp. 329-359, 2008.
259-262. 1995
[Kim03] D.-K. Kim A meta-modeling approach to
[Gri19] Griffith I. Design Pattern Decay A Study specifying patterns. Ph.D. Disseration, 2003.
of Design Pattern Grime and its Impact on
Quality and Technical Debt. PhD Disserta- [Lu11] Lu, Lunjin and D.-K. Kim Required behavior
tion in progress. of sequence diagrams: Semantics and refine-
ment 16th IEEE International Conference on
[Mar03] Martin R. Agile software development: prin- Engineering of Complex Computer Systems,
ciples, patterns, and practices. Prentice Hall pp. 127-136, 2011.
PTR, 2003.
11