e-Informatica Software Engineering Journal, Volume 4, Issue 1, 2010

Hierarchical Model for

Evaluating Software Design Quality
Paweł Martenka∗ , Bartosz Walter∗
∗
Institute of Computing Science, Poznań University of Technology
pawel.martenka@cs.put.poznan.pl, bartosz.walter@cs.put.poznan.pl

Abstract
Quality of software design has a decisive impact on several quality attributes of the resulting
product. However, simple metrics, despite of their popularity, fail to deliver comprehensive infor-
mation about the reasons of the anomalies and relation between them and metric values. More
complex models that combine multiple metrics to detect a given anomaly are still only partially
useful without proper interpretation. In the paper we propose a hierarchical model that extend
the Factor-Strategy model defined by Marinescu in two ways: by embedding a new interpretation
delivery mechanism into the model and extending the spectrum of data providing input to the
model.

1. Introduction quired to examine the values and identify the

problem.
Software design is considered one of the most 2. A vector of metric values has no meaning
complex human creative activities [13]. As such, for the designer without a proper interpreta-
the design process is prone to making errors, tion. Aggregate metrics are not subject to a
which significantly affect the quality of a soft- straightforward interpretation.
ware product resulting from the design. There- 3. Code metrics are unable to deliver complete
fore, there is a continuous search for mod- information about software design. They
els and approaches that could help both im- need to be combined with diversed set of
proving the design process and evaluating its data to provide a more complete view.
quality. Then, there is a need for more holistic ap-
Since software design is a quantifiable pro- proaches. One of them is a two-stage Fac-
cess, well-known code metrics are advocated as tor-Strategy proposed by Marinescu ([17]),
the primary solution for that problem. They are which is still based on metrics, but also ad-
easy to compute, there is also plenty of exper- dresses some of their weaknesses. It is a frame-
imental data showing the correlation between work for building rule-based descriptions of
various metrics and desired quality attributes. design anomalies, which builds a navigable
However, metrics are just numbers, which often path between metrics and actual violations of
do not point to the design flaws, but rather pro- high-level design principles. Unfortunately, this
vide rough and aggregate data. There are three approach has also drawbacks. Such principles
main drawbacks of using the isolated metrics as usually refer to abstract notions like cohesion
direct providers of quality-related information: or coupling, which still are not directly pointing
1. There is no direct traceable connection be- to actual flaws. Moreover, actual code anomalies
tween an actual cause and the value of a often result from multiple violations of different
metric; usually it is the designer who is re- nature, for which the rules could be not properly
22 Paweł Martenka, Bartosz Walter

configured. For example, the Large Class bad generalized, aggregate metrics. As an effect, they
smell [12], which describes classes bearing too proposed several specific metrics, which anal-
much responsibility, typically denotes an overly ysed different flavours of cohesion and coupling.
complex, low-cohesive class with lots of mem- Some researchers went in the opposite direc-
bers. Due to a large number of symptoms sug- tion, building more holistic approaches to mod-
gesting the presence of the flaw, metrics point- elling design anomalies. Beck, the author of eX-
ings to them must be combined and evaluated in treme Programming methodology, coined a term
non-linear and fuzzy manner to deliver an effec- of “code bad smell” for a general label for de-
tive and useful measurement mechanism. Thus, scribing structures in the code that suggest for
the Factor-Strategy model, which is based on the possibility of refactoring [11]. Since specific
simple and strict rules, still does not provide a smells describe anomalies that can result from
flexible abstraction for such flaws. many initial causes, they should also be backed
In this paper we propose a hierarchical model by several symptoms [23], e.g. diversed sets of
for evaluating design quality which is based on metrics. Moonen et al. [22] proposed a method
the Factor-Strategy concept, but extends it in for automating smell detection based on analysis
several ways. It provides designers with hierar- of source code abstract syntax trees. Kothari et
chical, custom-grained information, which helps al. in [16] defined a framework for building tools
in tracing the causes of flaws, and also enriches that perform partially automated code inspec-
the spectrum of utilized sources of data. tions and transformations.
The paper is structured as follows. Section 2 Dhambri et al. in [8] proceeded a step fur-
provides an overview of existing literature and ther and employed visualisation techniques for
approaches used for similar problems. In Sec- detecting anomalies. The main idea was based
tion 3 we present Factor-Strategy model in a on presenting some software quality attributes
more detailed way, and in Section 4 we propose (e.g. measured by metrics) to a software design
the hierarchical model. Section 5 contains a sim- expert, who made the final decision. Another
ple exemplary instance of the model, along with work, by Simon and Lewerentz [21], focused on
early experimental evaluation results. Section 6 refactorings driven by distance based cohesion.
summarizes our findings and proposes further Distance between members of classes (fields and
extensions to the model. methods) was visualised in a 3D space, so that
an expert could decide on appropriate assign-
ment of class members and possibly suggest
2. Related Work refactorings.
Based on critics of the simplistic
Historically, first attempts to quantitatively metric-based quality models, Marinescu pro-
evaluate the design quality of object-oriented posed Factor-Strategy model [17], composed of
software were directly derived from code met- two stages: detection strategies stage respon-
rics. Metric suites proposed by Chidamber and sible for identifying an anomaly, and composi-
Kemerer [6], e Abreu [9] and others were de- tion stage that evaluates the impact of suspects
signed to capture the most important inter- found in the previous step on the high-level
nal characteristics of object oriented software, quality factors.
like cohesion and coupling, and the use of This model was further extended. Ratiu [20]
mechanisms embedded in the object paradigm. encapsulated the detection strategies with a new
A strong evidence has been collected pointing to model which incorporated code changes his-
correlation between these metrics and external tory into the classification mechanism. The new
quality characteristics. model has two main advantages:
These characteristics were further investi- 1. removes false positives from the detected sus-
gated by Briand et al. [3, 2], who noted that they pects set,
are too ambiguous to be effectively captured by 2. emphasizes the most harmful suspects.
Hierarchical Model for Evaluating Software Design Quality 23

Similar concept – use of historical data – was and LowerThan filters, and composed with and
also exploited by Graves et al. [14] and Khosh- composition operator.
goftaar et al. [15]. Graves presented a few models Application of DS on a set of software enti-
to predict fault incidence and Khoshgoftaar in- ties (e.g. classes) results in:
troduced a regression model to predict software 1. a set of detected suspects,
reliability, both based on the code history. 2. a vector of metrics values for each suspect.
Using this data, a score for a DS is calcu-
lated and mapped to a normalised value (a
3. The Factor-Strategy Model ranked score). The score can be interpreted as
a higher-level metric for the strategy. Marinescu
As Marinescu noted, classical models of design provides a few exemplary formulas for comput-
quality evaluation do not provide explicit map- ing the score, for example the simplest is the
ping between metrics and quality criteria, so number of suspects for a given DS.
the rules behind quality quantification are im- Quantification of high-level quality factors is
plicit and informal. The metrics-based models based on an aggregation of ranked strategies and
can provide information about existence of a rules. Formulas for aggregation can vary from a
problem, but they do not reveal the actual cause simple mean value, where DS and the rules have
of a problem. Hence, there is a need for a more equal weight, to more sophisticated, weighted
comprehensive and holistic model. methods. Selection of a method for aggregation
The Factor-Strategy model has been pro- depends on the measurement goals. The aggre-
posed as a response to the above-mentioned gated value – which is a score for the quality fac-
weaknesses. It is composed of two main ele- tor, is also mapped to the ranked score to provide
ments: the Detection Strategy and the composi- qualitative information (labelled ranked scores).
tion step.
The Detection Strategy (DS) is defined as a
quantifiable expression of a rule by which design 4. Hierarchical Model
fragments that are conforming to that rule can
be detected in the source code. The Factor-Strategy model overcomes major
Rules are configured by a set of selected and problems of the classical solutions but still has
suitable metrics. In consequence, DS provides a a few drawbacks. The first doubt refers to the
more abstract level of interpretation than indi- completeness of strategies suite: they need to be
vidual metrics do, so that the numeric values of configured for every anomaly, so even the biggest
these metrics do not need to be interpreted in set of strategies does not cover all possible flaws.
isolation. The second weakness is concerned about
Metrics are combined into rules using two ba- limiting the data sources to metrics only.
sic mechanisms: filtering and composition. Fil- As noted in [23], anomalies typically require
ters transform metrics values whereas the com- multi-criteria detecting mechanisms, including
position operators aggregate into a rule. Mari- data from dynamic execution, configuration
nescu gives a following example of a Detection management repository, analysis of Abstract
Strategy instance for the Feature Envy smell: Syntax Tree patterns etc. Ratiu and others
FeatureEnvy := ((AID, HigherThan(4)) [20, 14, 15] proved usefulness of historical data
and (AID, TopValues(10%)) for quality evaluation. Van Emden [22] and Bax-
and (ALD, LowerThan(3)) and (NIC, ter [1] presented examples how Abstract Syn-
LowerThan(3)) tax Trees (ASTs) could be exploited as a source
This examplary rule uses three metrics: Ac- of quality-related data. The extended spectrum
cess of Import-Data (AID), Access of Local of sensor types, embedded into Factor-Strategy
Data (ALD) and Number of Import Classes model, may improve its sensitivity, accuracy
(NIC) processed with HigherThan, TopValues and correctness.
24 Paweł Martenka, Bartosz Walter

The final remark refers to the fact that oper- rently or – on the other hand – remain ignored
ators used for defining detection rules are strict, by existing strategies.
ie. they define a borderline, which may classify The analysis mechanism present in the hier-
very similar entities to different categories. Pro- archical model can be divided into three parts:
vided that the borderline is set up arbitrary, it 1. new data selection approach,
can significantly affect the results of evaluation. 2. metrics quantisation,
The goal of this research is to develop 3. entity-level aggregation.
a hierarchical model which tackles the men-
tioned problems and weaknesses. It extends the 4.2.1. Data Selection
Factor-Strategy model mainly in two areas:
1. diversed data sources are used instead of Classical quality models employ a set of se-
metrics only, lected metrics for evaluation of quality factor
2. a simple mechanism for dealing with fuzzy (or factors). For example, a model presented
problems is proposed. by Briand et al. in [4] is built upon metrics
which are supposed to measure coupling, inheri-
4.1. Structure of the Model tance, polymorphism and size, and is oriented on
fault-proneness prediction. Also instances of De-
The structure of the hierarchical model and tection Strategies in [17] consist of diverse sets
its relation to the Factor-Strategy approach is of metrics.
shown on Fig. 1. At the top of the model The model presented in this section pro-
there are high-level quality criteria (or char- motes different approach. Typically, behind ev-
acteristics), which are combined with detected ery principle of software design an internal qual-
lower-level patterns and rules violations. Pat- ity characteristic is present. Based on this obser-
tern and rule detection methods are supported vation, the selection of metrics should be strictly
by data coming from various data sources, oriented on such characteristic. On the other
e.g. metrics, historical data, results of dynamic hand, the selected metrics should be simple,
behaviour and abstract syntax trees (AST), suitable and adequate in the context of mea-
which improves accuracy of the detection sured characteristic. As a consequence, some
mechanism. types of metrics should be avoided:
The model schema shows a hierarchy of el- 1. strongly aggregating measures, like COF
ements, but also a hierarchy of information. (Coupling Factor defined by Abreu et al.
The evaluation criteria provide the most ab- in [9]), which are biased by compensation
stract and the most aggregated information. A problem – some parts of highly-coupled de-
designer can track down the hierarchy to get sign can be masked by parts which are
more detailed information and find the cause of loosely-coupled,
a problem indicated by the criteria. 2. metrics which are ambiguously defined, or
those capturing ambiguous concepts; Khaled
4.2. Analysis of Detection Rules and El-Emam in [10] argues that the notion of
Design Principles cohesion is too general to provide significant
results,
Detection strategies, which are the core part 3. metrics which try to capture multiple char-
of the original Factor-Strategy model, are con- acteristics at a time or appear not related to
figurable sets of rules aiming at capturing vi- the expected characteristic, eg. Basili et al.
olations of the well-known principles of design, in [5] argue that WMC metric actually mea-
based on quantified data. However, actual design sures software size instead of complexity.
anomalies present in code do not always match Following the postulate of diversed data
the predicted and configured set of strategies. sources, the model creation process should in-
They can also violate multiple principles concur- corporate as many sources as is needed to
Hierarchical Model for Evaluating Software Design Quality 25

High-level quality criteria

Combination

Pattern detection Rules analysis

Data gathering

Metrics Historical data Dynamic behaviour AST

Figure 1. Hierarchical quality model

increase interpretability of the results. New of a metric exceeds threshold, then the measured
patterns and existing strategies may be built attribute is considered to negatively impact the
with extended spectrum of data coming from quality. The domain of the metric is divided into
new sources. two intervals, which can be labelled as “negative
impact” and “no impact”. Thus, the labels pro-
4.2.2. Metrics Quantization vides interpretation for metrics values.
However, strict threshold values are inflex-
As pointed out by Marinescu in [17], a sim- ible, because values close to the threshold can
ple vector of metrics values is not very useful, be interpreted incorrectly in certain context. To
because there is no clear connection between provide a simple fix for that, the strict threshold
measures and quality factors. In other words, value can be replaced with an additional interval
such values require of proper interpretation. The representing the uncertainty. Values which falls
method presented below provides a new inter- into this interval should be analysed separately
pretation mechanism for metrics, so that vio- or supported by other data sources for correct
lations of rules can be detected and presented classification.
to the designer in intuitive way. In the context Having considered these arguments, we can
of the violated rules, we require an answer to define three classes (intervals) of the attribute
the question: is the value of a metric unaccept- domain:
able and, in consequence, measured character- 1. L – a value of a metric is unambiguously ac-
istic has negative impact on quality? The sim- ceptable, and the measured attribute has no
plest solution introduces a threshold: if a value or negligible negative impact on quality,
26 Paweł Martenka, Bartosz Walter

2. M – a value of a metric is near to threshold; pects and variations of those characteristics (e.g.
additional analysis is required or other data coupling can be divided into import and export).
sources should be explored, Therefore, an aggregation function of a set of
3. H – a value of a metric is unambiguously un- quantised metrics and other data sources has to
acceptable, and the measured attribute has be engaged, to answer the question: Does a com-
negative impact on quality. pound attribute, expressed by a set of input data,
We can formally define the labelling phase in have a negative impact on quality? Let be defined:
following way: 1. Mp – a set of metrics to express principle p,
1. E – a set of analysed entities, for example a in other words, a set of metrics suitable for
class or a package, detection of violations of the principle,
2. M – a set of all metrics, suitable for the con- 2. Ae,p – a set of all additional pieces of in-
structed model, formation, extracted from the other data
3. L – a set of all labels which identify classes sources (not metrics), for entity e and prin-
of impact, ciple p,
4. P – a set of all principles considered in the 3. Me,p = {(m, mlie,m ) : e ∈ E, p ∈ P, mlie,m ∈
model, L, ∀(m ∈ Mp )mlie,m = αm (m(e))} – a set of
5. m – a metric (e.g. CBO), pairs: metric with assigned label; the label
6. m(e), e ∈ E – a value of metric m for entity e. is assigned respectively to formula (1); the
set is evaluated for all metrics referring to
mlie,m = αm (m(e)), e ∈ E, m ∈ M, mlie,m ∈ L.
principle p and calculated for entity e.
(1)
Function described by formula (1) maps a value plie,p = βp (Me,p , Ae,p ), e ∈ E, p ∈ P, plie,p ∈ L.
of a metric m, measured for entity e, to a label (2)
mli 1 . As an effect, a numerical value delivered Function defined by formula (2) aggregates a set
by a metric is replaced by a higher-lever label, of labelled metrics and additional information to
which is already interpreted from the quality label pli 2 , which denotes impact of underlying
point of view. characteristic on quality. Aggregation defined by
The entire effort in the construction of this formula (2) may be also realized as a classifier3 .
part of the model must be devoted to defin- Assuming labels l ∈ L denotes classes, the clas-
ing the α function. For the basic version of the sifier built for specific principle p will assign a
model (with three classes) at least one threshold class l to an entity e. Meaning of the aggregated
value with surrounding interval must be defined. label or class can be generalised as follows: label
The crucial step deals with identification of a l ∈ L denotes strength of negative impact of an
threshold and a width of the interval. attribute upon quality.
The quantised metric – the labelled value – Aggregation step requires careful interpreta-
is only the very first and preliminary interpreta- tion of collected results, especially in the case
tion step. This information is valuable in larger of compound characteristics. To sum up above
context, thus labelled metrics should be utilised considerations:
in compound patterns and strategies. 1. well-known principles of software design are
always based upon internal quality charac-
4.2.3. Entity-level Aggregation teristic,
2. such characteristics can be decomposed into
Some of the characteristics and mechanisms, elements which can be later evaluated by
which constitute the basis for the rules of good data coming from diverse data sources. The
design, are so complicated that there is a need for collected results are useful for detection of
many supporting data sources, to capture all as- violations of principles,
1
Metric-level impact.
2
Principle-level impact.
3
For example using decision rules or trees.
Hierarchical Model for Evaluating Software Design Quality 27

3. aggregated results say nothing about the 5.1.2. Principles

quality characteristic they are based on, but
provide information about the negative im- Coupling concept is considered to be a good pre-
pact of a measured attribute on quality. dictor of quality. El-Emam in [10] provides evi-
Label evaluated by formula (2) denotes impact, dence that high coupling makes programs hard
but do not identify a violation of a principle. To to understand. Rule of low coupling, identified
define a violation, let be assumed: by Coad and Yourdon in [7] is selected as the
1. V Lp – a set of labels, which are treated as a design principle used as quality criterion in this
violation of principle p, example. Hence, let us define a set of principles
2. Vp – a symbol of a violation of rule p. P = {LowCoupling}.

plie,p ∈ V Lp ⇒ Vp , e ∈ E, p ∈ P. (3) 5.1.3. Data Sources

Definition If aggregated label pli for a charac- For the purpose of coupling measurement, met-
teristic supporting principle p, for analysed en- rics Ca and Ce, defined by Robert Martin in
tity e, belongs to the set VL, then the entity is [18], are used. The metrics count incoming (Ce)
flawed by a violation of rule p. and outgoing (Ca) couplings separately, and will
This definition is captured by formula (3). be applied at class level. Additional information,
The detected violations can be scored and based on abstract syntax tree, is defined as a flag
ranked just like Detection Strategies. As a indicating whether an entity (a class in this case)
consequence, presented method can be homo- is abstract. Let us assume:
geneously in-lined with methods presented in 1. M = MLowCoupling = {Ca, Ce} – a set of all
Factor-Strategy model. metrics is actually the set of metrics for the
design principle LowCoupling, because only
one design principle is considered,
5. Example of Application 2. A = {IsAbstract} – additional information
from a non-metrics source.
This section brings through a process of instan-
tiation of a fragment of the hierarchical model. 5.1.4. Definition of Quantization and
Scope of the example is narrowed to the ele- Aggregation
ments which constitutes novelty of the model:
rules analysis method with metrics quantization As described in [10] by [19], a human can cope
and aggregation. Instantiated model will be ap- with 7±2 pieces of information at a time. We use
plied to exemplary entities. this observation as a threshold for the above-se-
lected coupling measures. For a quantization
5.1. Model Creation purpose, let us define:
1. L = {L, M, H} – the basic set of labels,
2. αCe (Ce(e)):
5.1.1. Goals

The very first step of a model creation is the  L, Ce(e) < 5
selection of quality characteristic to be eval- mlie,Ce = M, Ce(e) ∈ [5, 9] (4)
uated. Following activities, like principles and H, Ce(e) > 9

metrics selection, are made in the context of the
3. αCa (Ca(e)):
high-level quality goal. For the purpose of this
example, readability (but analysability and un- 
 L, Ca(e) < 5
derstandability are closely related) of code and mlie,Ca = M, Ca(e) ∈ [5, 9] (5)
design is selected as a goal and high-level quality 
H, Ca(e) > 9
factor.
28 Paweł Martenka, Bartosz Walter

The model is oriented toward detection of 2. MAmeChat,LowCoupling = {(Ce, H), (Ca, H)}
violations, so the simple max function will 3. MDrawableGroup,LowCoupling = {(Ce, L),
be used for aggregation, assuming that la- (Ca, H)}
bels are ordered from the lowest value of 4. ADisplayM anager,LowCoupling = {IsAbstract =
L to highest H. Martin in [18] argues that F alse}
classes should depend upon the most stable 5. AAmeChat,LowCoupling = {IsAbstract =
of them (eg. on abstract classes), so if a T rue}
class is abstract then export coupling (Ca) is 6. ADrawableGroup,LowCoupling = {IsAbstract =
not taken into consideration. Aggregation func- F alse}
tion βLowCoupling (Me,LowCoupling , Ae,LowCoupling ) Results of aggregation of quantized metrics:
is defined as follows: 1. pliDisplayM anager,LowCoupling = max{H, M }
 =H
 mlie,Ce , IsAbstract(e) 2. pliAmeChat,LowCoupling = mliAmeChat,Ce = H
plie,LowCoupling = max{mlie,Ce , mlie,Ca }, 3. pliDrawableGroup,LowCoupling = max{L, H}
otherwise

=H
(6) Regarding the previous definitions of violations,
Finally, let us define the violation: all entities violate the principle of low coupling
1. V LLowCoupling = {M, H} – a set of labels and negatively affect the high-level quality cri-
indicating violations of LowCoupling rule; la- terion.
bel M is also included to capture entities
which probably violate the rule, 5.2.1. Interpretation
2. VLowCoupling – a symbol which denotes vio-
lation of LowCoupling rule, The high-level quality goal – readability – is
3. (plie,LowCoupling ∈ V LLowCoupling ) ⇒ not evaluated because there are too few entities
VLowCoupling – definition of LowCoupling rule to get a relevant output. Let be assumed, the
violation. high-level factor indicates a problem in software.
The very first step is to look for strategies and
principles which support the factor, and choose
5.2. Application
only those with current negative consequences.
The model will be applied on sample data, The second step is to look for entities (suspects)
taken from a student project, depicted in ta- which negatively impacts the factor in the con-
ble 1. All classes are large (from 384 lines to 477 text of chosen principle (or strategy). In this par-
lines in a file) and probably flawed in many as- ticular example there are only three classes and
pects. Results generated by the model are com- all of them are suspects due to violations of the
pared to results gathered in a survey, conducted principle.
among graduate software engineering students Violation in DisplayManager results from
(students were asked to identify classes that are the metric Ce, labelled with H, and Ca la-
too large). belled with M. Considering Ce definition, Dis-
The quantized metrics and additional data playManager suffers mainly from import cou-
for all entities: pling, and moderately from export coupling. Re-
1. MDisplayM anager,LowCoupling = {(Ce, H), spondents classified DisplayManager as Middle
(Ca, M )}
Table 1. Sample data
Class Ce Ca mlie,Ce mlie,Ca IsAbstract
DisplayManager 13 8 H M False
AmeChat 14 35 H H True
DrawableGroup 4 14 L H False
Hierarchical Model for Evaluating Software Design Quality 29

Man and Large Class, and model results can in- page 368, Washington, DC, USA, 1998. IEEE
dicate causes of these smells. Computer Society.
AmeChat is an abstract class, so it is ob- [2] L. C. Briand, J. W. Daly, and J. K. Wüst.
vious that it is used by many other classes. In A unified framework for cohesion measurement
in object-oriented systems. Empirical Software
consequence, only import coupling is considered,
Engineering, 3(1):65–117, 1998.
so the impact results from Ce, despite of high [3] L. C. Briand, J. W. Daly, and J. K. Wüst. A
value of Ca. The vast majority of the respon- unified framework for coupling measurement in
dents identified Large Class smell, which can be object-oriented systems. IEEE Transactions on
connected with high import coupling. Software Engineering, 25:1, 1999.
DrawableGroup uses desirable amount of [4] L. C. Briand, W. L. Melo, and J. Wüst. Assess-
classes, Ce=L, but is used in many other places. ing the applicability of fault-proneness models
across object-oriented software projects. Tech-
The majority of the respondents identified Re-
nical report, ISERN, 2000.
fused Bequest in the class. This smell deals [5] L. C. Briand, S. Morasca, and V. R. Basili.
with inheritance, which is not considered in Property-based software engineering measure-
this model. Obtained results indicates other, ment. IEEE Transactions on Software Engi-
coupling-related problems which probably can- neering, 22:68–86, 1994.
not be named as a defined smell. [6] S. R. Chidamber and C. F. Kemerer. A metrics
suite for object oriented design. IEEE Transac-
tions on Software Engineering, 20(6):476–493,
1994.
6. Summary [7] P. Coad and E. Yourdon. Object Oriented De-
sign. Prentice Hall, 1991.
The proposed hierarchical model extends the [8] K. Dhambri, H. A. Sahraoui, and P. Poulin.
Factor-Strategy model in three ways. It delivers Visual detection of design anomalies. In 12th
more comprehensive and traceable information European Conference on Software Maintenance
concerning detected potential anomalies to the and Reengineering 2008, pages 279–283, April
designer, including the interpretation of metrics 2008.
[9] F. B. e Abreu and R. Carapuça. Object-oriented
values, and also broadens the spectrum of anal-
software engineering: Measuring and controlling
ysed data sources to the non-metric ones. As the development process. In Proceedings of the
the simple example suggests, these elements help 4th International Conference on Software Qual-
in discovering new types of anomalies and also ity, 1994.
support the designer in evaluating the impact, [10] K. E. Emam. Advances in Software Engineer-
scope and importance of the violation. It also ing, chapter Object-Oriented Metrics: A Review
delivers hierarchically structured data justifying of Theory and Practice, pages 23–50. 2002.
[11] M. Fowler. Refactoring. Improving the Design
the suspected flaws, and includes a uncertainty
of Existing Code. Addison-Wesley, 1999.
interval. Therefore, the model more resembles [12] M. Fowler, K. Beck, J. Brant, W. Opdyke, and
the human way of cognition. D. Roberts. Refactoring: Improving the Design
Further directions of research include an ex- of Existing Code. Addison-Wesley, 1999.
perimental validation of the model, defining de- [13] R. Glass. On design. Journal of Systems and
tection strategies utilizing data from heteroge- Software, 52(1):1–2, May 2000.
neous data sources, and also embedding internal [14] T. L. Graves, A. F. Karr, J. Marron, and H. Siy.
design characteristics into the model. Predicting fault incidence using software change
history. IEEE Transactions on Software Engi-
neering, 26:653–661, 2000.
References [15] T. M. Khoshgoftaar, E. B. Allen, R. Halstead,
G. P. Trio, and R. M. Flass. Using process
[1] I. D. Baxter, A. Yahin, L. Moura, M. Sant’Anna, history to predict software quality. Computer,
and L. Bier. Clone detection using abstract syn- 31:66–72, 1998.
tax trees. In ICSM ’98: Proceedings of the Inter- [16] S. C. Kothari, L. Bishop, J. Sauceda, and
national Conference on Software Maintenance, G. Daugherty. A pattern-based framework for
30 Paweł Martenka, Bartosz Walter

software anomaly detection. Software Quality [21] F. Simon, F. Steinbrückner, and C. Lewerentz.
Control, 12(2):99–120, 2004. Metrics based refactoring. In Proceedings of the
[17] R. Marinescu. Measurement and Quality in 5th European Conference on Software Mainte-
Object-Oriented Design. PhD thesis, “Politeh- nance and Reengineering, pages 30–38, 2001.
nica” University of Timişoara, 2002. [22] E. van Emden and L. Moonen. Java quality
[18] R. Martin. OO design quality metrics. An anal- assurance by detecting code smells. In Proceed-
ysis of dependencies. Report on Object Analysis ings of the 9th Working Conference on Reverse
and Design, 2(3), 1995. Engineering, 2002.
[19] G. Miller. The magical number seven, plus or [23] B. Walter and B. Pietrzak. Multi-criteria detec-
minus two: Some limits on our capacity for pro- tion of bad smells in code with UTA method.
cessing information. The Psychological Review, In Proceedings of XP 2005 conference, pages
(63):81–97, 1956. 154–161, 2005.
[20] D. Ratiu, S. Ducasse, T. Grba, and R. Mari-
nescu. Using history information to improve
design flaws detection, 2004.