On using UML Diagrams to

Identify and Assess Software Design Smells

Thorsten Haendler

Institute for Information Systems and New Media,

Vienna U niversity of Economics and Business, Vienna, Austria

Keywords:

Software Design Smells, Uniﬁed Modeling Language (UML2), Smell Detection and Assessment, Code

and Design Review, Software Design Documentation, Refactoring, Architectural Smells, Technical Debt

Management.

Abstract:

Deﬁciencies in software design or architecture can severely impede and slow down the software development

and maintenance progress. Bad smells and anti-patterns can be an indicator for poor software design and

suggest for refactoring the affected source code fragment. In recent years, multiple techniques and tools have

been proposed to assist software engineers in identifying smells and guiding them through corresponding

refactoring steps. However, these detection tools only cover a modest amount of smells so far and also tend

to produce false positives which represent conscious constructs with symptoms similar or i dentical to actual

bad smells (e.g., design patterns). These and other issues in the detection process demand for a code or design

review in order to identify (missed) design smells and/or re-assess detected smell candidates. U ML diagrams

are the quasi-standard for documenting software design and are often available in software projects. In this

position paper, we investigate whether (and to which extend) UML diagrams can be used for i dentifying and

assessing design smells. Based on a description of difﬁculties in the smell detection process, we discuss the

importance of design reviews. We then investigate to which extend design documentation in terms of UML2

diagrams allows for representing and identifying software design smells. In particular, 14 kinds of design

smells and their representability in UML class and sequence diagrams are analyzed. In addition, we discuss

further challenges for UML-based identiﬁcation and assessment of bad smells.

1 INTRODUCTION

Deﬁciencies in software design o r arc hitecture can se-

verely impede and slow down the maintainability and

extensibility of a software system (technical deb t),

see e.g., (Kruchten et al., 2012). Bad smells and anti-

patterns can be an indicator for poo r software design

and suggest for refactoring the affected source code

fragment (Fowler et al., 1999). Smells can be fo und at

different levels (i.e. on level of software source code,

software design, an d software architecture). So ftware

design smells, in particular, rep resent ﬂaws in soft-

ware design by violating design rules (Suryanara y-

ana et al., 2014). They can be categorized into AB-

STRACTION, ENCAPSULATION, HIERARCHY, and

MODULARIZATION smells.

In recent years, multiple tools and techniques have

been proposed for assisting software engineers in de-

tecting and assessing refactoring candidates as well as

planning and performing refactoring steps, see, e.g.,

(Fernandes et al., 2016). Despite these efforts and ad-

vances, several difﬁculties in the proc ess of smell de-

tection and refactoring still demand for an individual

assessment of smell candidates by human experts,

also see, e.g., (Tempero et al., 2017) . For instance,

smell detectors only cover a modest amount of smell

kinds and are mostly only available for selected pro-

gramming languages, see, e.g., (Fontana et al., 2012;

Fernandes et al., 2016). Moreover, smell detection

tools also produce smell false positives (Fontana et al.,

2016).

These issues in the detection proc ess dem and for

a design or code review in o rder to identify (missed)

design smells (false negatives), to re- assess detected

candidates in order to discard false positives and/or

to prioritize the candidates for refactoring, see, e.g.,

(Ribeiro et a l., 2016). For th is review, o ften an expli-

cit software design do cumentation, e.g., in terms of

diagrams of the Uniﬁed Modeling Lan guage (UML2)

(Object Management Group, 2015), can be consulted

by software en gineers to investigate the design quality

of the software system.

Haendler, T.

On using UML Diagrams to Identify and Assess Software Design Smells.

DOI: 10.5220/0006938504130421

In Proceedings of the 13th International Conference on Software Technologies (ICSOFT 2018), pages 413-421

ISBN: 978-989-758-320-9

413

In this position paper, we investigate the applica-

bility of UML -based documentation for identifying

and assessing so ftware design smells. The hypothesis

is that UML design diagra ms are suitable as decision-

support for recognizing software design issues. Ba-

sed on an overview of difﬁculties in the process of

detecting and assessing design smells, we focus on

answering the questio n, whether and to which extend

software design smells can be identiﬁed via reviewing

UML-based de sig n documentation of the system un-

der analysis. For th is purpose, we analyze 14 diffe-

rent kind s of software design smells reported in rese-

arch literature (see, e.g., (Fowler et al., 1 999; Sury-

anarayana et al., 2014)) regarding their representabi-

lity via UML class and sequence diagrams (based on

smell sym ptoms and relevant design context). Mo-

reover, we discuss further challenges f or using UML

diagrams to identify and assess bad smells, such as

the availability and quality of d esign documentatio n,

the identiﬁability of false positives and alternative

decision-support tech niques.

Paper Structure. The remainder of this paper is

structured as follows. Section 2 gives an overview

on several difﬁculties in detecting and assessing de -

sign smells in general for motivating the importan c e

of design reviews. In Section 3, we investigate the

identiﬁability of design smells via reviewing UM L2

diagrams. In particular, we analyz e the applicability

of UML diagrams f or repre senting 14 kinds of design

smells and discuss further challenges for the UML-

based identiﬁcatio n/assessment. Section 4 reﬂects on

related work . In Section 5, the limitations of the ap-

proach are discussed, and Section 6 concludes the pa-

per.

2 DIFFICULTIES IN

IDENTIFYING AND

ASSESSING DESIGN SMELLS

The process of identifying candidates for refactoring

can be rou ghly divided into the following two steps:

ﬁrst, detecting sme ll candidates and, second, assess

the can didates in order to ru le out whe ther the candi-

date should be refactored or not. Table 1 provides

an overview of 14 k inds of software design smells

with aspects relating to difﬁculties in identiﬁcation

and assessment. The smells represent a subset of the

design smells covered by (Fowler et al., 1999) an d

(Suryan arayana et al., 2014)

and will later be ex-

(Fowler et al., 1999) describe symptoms, causes and

variants as well as refactoring options for 22 code smells,

amined regarding their r epresentability in UML di-

agrams (see Section 3). For each smell kind, po-

pular aliases (or very similar smells) used in rese-

arch literature or industrial practice are listed. The

smells are catego rized by the violated design princi-

ple (or rule; i.e. ABSTRACTION, ENCAPSULATION,

HIERARCHY, and MODULARIZATION). Also a short

description of smell symptoms is provided, based on

(Fowler et al., 1999; Sur yanarayana et al., 2014).

Smell Coverag e of Detection Tools. In recent ye-

ars, multiple tools and tech niques addressing the de-

tection of smells ( ﬁrst step) have been proposed. For

an overview, see, e.g., (Fontana et al., 2012; Fernan-

des e t al., 2016). For spotting sm ell candidates via

symptoms, de te c tion tools apply rules and threshold

based on different metrics mostly by leveraging static

program analysis techniques. In general, these tools

come with certain limitations regarding the availabi-

lity for programming languages (mostly only a few

languag es) and the quite moderate coverage of smell

kinds, especially fo r smells that ar e categorized as de-

sign smells (see below).

Table 1 illustrates the smell coverage of two popu-

lar smell d etectors (DECOR and JDeodorant w hich

analyze the source code using static analysis techni-

ques) and of one popular UML model smell detec-

tor (EMF Refactor). The chosen detectors are exem-

plary, but representative regarding the amount of co-

vered smell k inds; see, e.g., (Fontana et al., 2012 ).

The detectors DECOR (Moha et al., 2010) and JDeo-

dorant (Tsantalis, 2017) are available for Java-based

programs only; both also provide automated re facto-

ring for the detected smells.

• Among the 9 sm e lls detec ted by DECOR only 4

can be ca tego rized as design smells, wh ic h are in

particular DATACLASS, LARGECLASS, MESSA-

GECHAIN and SPECULATIVEGENERALITY.

• JDeodorant covers 5 sme lls, of which 3 are d esign

smells; i.e. FEATUREENVY, MULTIFACEDAB-

STRACTION (in terms of GODCLASS), and DU-

PLICATEABSTRACTION (in terms of DUPLICA-

TEDCODE).

• E MF Refactor is a Eclipse plugin i.a. for de-

tecting and refactoring smells in UML models.

In total, it addre sses 27 kinds of smells, of

which 6 can be seen as design smells; i.e. DA-

TACLUMPS, LARGECLASS, SPECULATIVEGE-

NERALITY, DIAMONDINHERITANCE, UNUSE-

DCLASS, and DUPLICATEABSTRACTION ( but

only in terms of EQUALLYNAMEDCLASS).

of which some are design smells. (Suryanarayana et al .,

2014) destinguish 25 explicit software design smells.

ICSOFT 2018 - 13th International Conference on Software Technologies

414

Table 1: Overview of 14 software design smells categorized by design principles (violated by the smells) with aliases and

symptoms. The smell coverage by popular smell detectors and the exemplary false positives illustrate the importance of

design r eviews for identifying and assessing smell candidates.

Violated

Design Princ.

Software design smell

based on (Fowler et al.,

1999; Suryanarayana

et al., 2014)

Aliases

(used in research or in-

dustry) and smells with

similar symptoms

Symptoms description

based on (Fowler et al., 1999; Suryanarayana

et al., 2014)

DECOR

JDeodorant

EMF Refactor

Smell false positives

oriented to (Fontana et al.,

2016)

AB S T R ACTIO N

DATACL U M P (a kind of) MISSINGAB-

STRACTION

Clumps of data used instead of a unit (e.g.,

class)

– –

√

–

MU LTIFACEDABST R ACTION LARGECLASS, G OD-

CLASS, lack o f cohesion

Unit (e.g., classes) with more than one respon-

sibility

√

S TATE DP, ge n eric class, e.g.,

conﬁguration class, GUI widget

toolkits

UN U T ILIZEDABSTRACTION UNUSEDCLASS, SPECU-

LATIVEGENERALITY

Not or barely used units (e.g., class or method)

√

–

√

recently developed program ele-

ments not yet covered by tests,

null implementation

DU P L ICATEAB S T R ACTION CODECLONE, DUPLI CA-

T EDCODE, functionally

similar methods (as

kind of DUPLICATEAB-

STRACTION)

Multiple units (classes or methods) with identical

(or similar) internal and/or external structure or

behavior

–

√

inherited or overridden method

DE FI C IENTENCAPSULATI ON Hideable p u blic attributes

or methods

The accessibility of attributes o r methods is

more permissive than actually required

– – – –

ENC A P S .

LE A K Y ENCAPSULATI O N – A unit that exposes implementation details via

its public interface

– – – –

SPE C U L ATIVEHI E R A R C H Y SPECULATIVEGENERALITY,

speculative general types

One or more types in a hiera rchy are used spe-

culatively (only based on imagined needs)

√

–

√

–

UN N E C ESSARYHIERARC H Y TAXOMANIA (taxonomy

mania)

A variation between classes is mainly/only cap-

tured in terms of data (structural features)

– – – –

DE E P HIERARCHY DISTORTEDHIERARCHY An unnecessaril y deep hiera r chy – – – –

HI E R ARCHY

MU LTIPATH HI ERARCHY REPEATEDINHERITANCE,

DIAMONDINHERITANCE

A subtype inherits both directly and indirectly

from a supertype

– –

√

–

FE ATUREENVY (a kind of) BROKENMO-

D ULARIZATION, Misplaced

operations

Methods are more interested in features owned

by foreign classes than in features of the owning

class

–

√

– VISITOR DP, STRATEGY DP, DE-

C ORATOR DP, P ROXY DP, ADAP-

T ER DP

DATACL A S S (a kind of) BROKENMO-

D ULARIZATION, RECORD-

CLASS, DATACONTAINER

Classes providing data but having no (or only

few) methods for operating on them

√

– – EXCE PTIONHANDLINGCLASS,

LOGGERCLASS, SERIALIZABLE-

CLASS, conﬁguration class, Data

Transfer Object (DTO)

CY C L ICDEPENDEND-

MO D U L A RIZATIO N

CYCLICDEPENDENCY,

(DEPENDENCY) CYCLES

Two or more units (e.g., classes, methods) mu-

tually de p end on each other

– – – VISITOR DP, OBSERVER DP, AB-

STRACTFACTORY DP

MO D U L A RIZATIO N

ME S S AG E CHAIN (a kind of) BROKENMODU-

LARIZATION

A client unit (e.g., method) calls another unit,

which then in turn calls another unit, and so on

(navigation through class structure)

√

– – BUILDER DP, FACADE DP, test-

class method

As also can be seen from Table 1, some of the se-

lected smell kinds are not covered or are only covered

partially.

Smell False Positives. Due to the ambivalence of

metrics-based smell detection, tools tend to produce

false positives. The symptoms which indicate a bad

smell can also be the result of code and design con-

structs, which have been consciously implemented by

a software engineer. (Fontana et al., 2016) identi-

ﬁed b ased on a literature review such false positives

for 12 code smells and anti-patterns, which represent

mainly ABSTRACTION and MODULARIZATION de-

sign smells, and provide corresponding false p ositi-

ves. The se smell false positives ca n be categorized a s

follows (Fontana et al., 2016):

• imposed anti-p atterns and smells (consciously

implemented) which are, e.g. , the result of ap-

plying a design patter n or imposed by using a spe-

ciﬁc programming language or framework, or by

performing optimizations.

• inadvertent anti-patterns and smells (created by

tools) whic h are, e.g., caused by source-cod e ge-

nerators or program r e presentation, or result in the

analysis scope.

We extended this list based on experience from soft-

ware projects (see the row at the right in Table 1).

For an overview of design patterns, also see (Gamma

et a l., 1995).

Design Reviews. The difﬁculties reﬂec te d above il-

lustrate that even by applying automated decision-

support tools for smell d e te ction fur ther human inves-

tigation is necessary in order to identify false negati-

ves (i.e. smells not detected by tools) and/o r to (re-)

assess detected candidates for d iscarding false posi-

tives. In addition, it is often ne c essary for so ftware

design evaluation to include contextual knowledge on

the design ra tionale provided by design experts such

as software architects. For this purpose, code and de-

sign reviews are performed. However, the dir e ct m a-

nually investigation of the source code can be tedious

and erroneous, especially for large software systems.

In addition, since some design issues do not manifest

via the source code, it can become difﬁcult to identify

them via a code review alone.

For this reason, in software projects often de-

sign docum entation based on the Uniﬁed Modeling

On using UML Diagrams to Identify and Assess Software Design Smells

415

Language (UML2) is available w hich represents the

quasi-standard for docume nting software design. The

UML provides notations for modeling structural and

behavioral software design aspects.

3 IDENTIFYING SOFTWARE

DESIGN SMELLS IN UML

DIAGRAMS

3.1 Representability of Design Smells in

UML Diagrams

In this section, we analyze th e app licability of UML2

class and seque nce diagrams to pr ovide relevant infor-

mation for software en gineers to identify a nd/or as-

sess software design smells during a d esign review.

The Uniﬁed Modeling Language (Object Manage-

ment Grou p, 2015) p rovides different diagrams types

for documenting structural and behavioral aspects of

object-oriented software systems.

Based on several studies, see, e.g., (Arisholm

et al., 2006; Scanniello et al., 2018), there is evi-

dence that the availability of design documentation

in software projects in terms of UML diagrams en-

hances the comprehe nsibility of program source-c ode

and can lead to signiﬁcant improvements regarding

the functional correctness of modiﬁcation task s, es-

pecially f or complex tasks ( such as the identiﬁcation

and refactoring of design smells).

For our investigation, we focus on UML2 class

and sequence diagrams, sin ce they a re the most com-

mon in industry projects for modeling structural and

behavioral d esign aspects respectively, see, e.g., (Lai-

tenberger et al., 2000):

• In particular, UML class diagrams rep resent the

class structure of a software system (i.a., with

attributes and operations) and relations between

these classes (e.g., in terms of associations, gene-

ralizations, and dependencie s) .

• UML sequen ce d ia grams in tur n represent inte-

ractions between class instances (i.e. objec ts) at

runtime. The objec ts are repre sented by lifelines

which interact by mutually exchanging messages

(e.g., method calls). This way, sequence diagrams

allow for doc umenting the intended or actual be-

havior of objects during (system) usage scenario s.

For investigating the UML-based representability

of the de sign smells, we describe the minima l structu-

ral and behavio ral de sig n scope which include all ele-

ments that are affected by the smell sy mptoms.

De-

For smell symptoms, see Table 1; for other aspects of

pending on the kind of smell, th is relevant context can

include structural and/or behavioral design aspects of

the system under ana lysis. Based on th e design con-

text, we then present exemplary UML class and se-

quence diagrams. For the purpose of comprehensibi-

lity, the diagrams are simple, syn thetic and syntacti-

cally reduced. Figs. 1, 2, 3 and 4 depict th e structural

and behavioral de sign scopes with exemplary UML-

based repre sentation in terms of UML cla ss and se-

quence diagrams. The smell symptoms are highligh-

ted in red. For each smell, we then discuss whether

the de sig n smell can be represented via the UML dia-

grams and whether r eviewing the d ia gram allows for

identifyin g the smell. This is, we reﬂect, whether the

correspo nding diagram provides the info rmation nee-

ded for smell identiﬁcation. In addition, where ap-

propriate, we reﬂect on other relevant difﬁculties for

smell identiﬁcation and assessment, especially b ased

on the UML diagrams.

ABSTRACTION Smells. Fig. 1 depicts the four AB-

STRACTION sm e lls with exemplary UML diagrams

reﬂecting the structural and behavioral design scopes.

• DATACLUMP: Since no informatio n on the data

usage is available in class diagrams, it does not

allow for identifying the smell. Based on multi-

ple sequence diagram s reﬂecting different usage

scenarios, a repeated joint usage of the data can

indicate a DATACLUMP smell.

• MULTIFACEDABSTRACTION: A class diagram

can weekly indicate a candidate for MULTIFA-

CEDABSTRACTION, e.g., by multiple relations-

hips (e.g., dependencies) from/to other classes.

This information can be com plemented by se-

quence diagrams (reﬂecting different usage scena-

rios), which might illu stra te that a class interacts

with certain other classes in different scen arios,

which can be seen as an indic ator for multiple re-

sponsibilities.

• UNUTILIZEDABSTRACTION: In case that a c la ss

has no (or very little) relationships to other clas-

ses, a class diagram indicates such a UNUTILI-

ZEDABSTRACTION. Given that the relationships

are deﬁned in source code, but never actually

used at runtime, the sequence diagrams can indi-

cate candidate s for functionally UNUTILIZEDAB-

STRACTIONs.

• DUPLICATEABSTRACTION: Candidates f or syn-

tactical duplicates can be spotted via class dia-

grams by comparing the owned features and rela-

smell detection/assessment and i ts refactoring (such as po-

tential causes, variants, or refactoring techniques), please

consult research literature such as (Fowler et al., 1999; Su-

ryanarayana et al., 2014).

ICSOFT 2018 - 13th International Conference on Software Technologies

416

A A'DuplicateAbstraction

:A :B :C

sd 1

:A' :B :C

sd 2

DataClump

:A :B :C

sd 1

:A :B :C

sd 2

MultifacedAbstraction

:D :B

sd 1

:A :B :C

sd 2

UnutilizedAbstraction

:A :B

A B C :C

Classes owning the

candidate data,

e.g., getter methods

a2(), b1(), and c3(),

used during a speci

c or

multiple usage scenarios

Interactions between

instances of owning

classes during

usage scenario(s)

(indicating that methods

a2(), b1() and c3() are

repeatedly used

together, in multiple

scenarios)

Design Smell Structural Scope Behavioral ScopeExemplary Class Diagram Exemplary Sequence Diagram

A CB

Candidate class (B)

with used/using methods

or attributes and

corresponding using/

used methods with

owning foreign classes

Interactions of candidate

class (B) with multiple

classes during di

erent

usage scenarios

(indicating that B holds

probably multiple

responsibilities)

Candidate class (C)

with using

classes/methods

(if rarely used)

In case of rarely used

class, interactions of it.

(else, no interaction

available for instances

of class C)

Candidate class

(A') with owned features

(e.g., methods and

attributes) and

relationships (if any)

(indicating syntactical

clone)

Interactions of instances

of candidate class (A')

in terms of calls from

and to the lifeline

(indicating functional

similar clone)

a2()

b1()

c3()

a2()

b1()

c3()

b1()

a2()

Figure 1: Selected ABSTRACTION smells with exemplary UML class and sequence diagrams reﬂecting the structural and

behavioral design scope and smell symptoms (see Tab. 1). Smell symptoms are highlighted in red.

tionships. In addition, sequence diagrams allow

for iden tifying candidates for semantic duplicates

in terms of functionally similar clones. For in-

stance, in case the sequences of calling and called

method (and the types of the passed arguments)

are ide ntical, a candid ate is ide ntiﬁed.

For all four ABSTRACTION smells (except for the

syntactical variants of UNUTILIZEDABSTRACTION

and DUPLICATEABSTRACTION) sequence diagrams

reﬂecting the usage scenarios are nece ssary to iden-

tify the corresponding smell candidates.

ENCAPSULATION Smells. In Fig. 2, the DEFI-

CIENTENCAPSULATION smell is depicted. A UML

class diagram alone p rovides information on the

access modiﬁer of the can didate feature. To investi-

gate how the attribute is ac tually used, sequence di-

agrams reﬂecting usage scenarios are need e d which

indicate that a candida te feature is not used by other

classes (which points to a DEFICIENTENCAPSULA-

TION smell).

HIERARCHY Smells. Fig. 3 depicts the four ad-

dressed HIERARCHY smells with UML examples.

• SPECULATIVEHIERARCHY: Based on the class

diagram alo ne, it can not be seen whether a hier-

archy is speculative, sinc no information on the

actual usage is available. The sequence diag ram,

in addition, might indica te that the inherited featu-

res of the candidate class are actually never used.

• For the three HIERARCHY smells UNNECESSA-

RYHIERARCHY, DEEPHIERARCHY and MULTI-

PATHHIERARCHY, class diagrams obviously can

indicate the cor responding smell candidates via

generalization relationships; UML sequence dia-

grams c an not be used for identiﬁcation here.

MODULARIZATION Smells. Fig. 4 de picts the dif-

ferent MODULARIZATION sme lls addressed in this

analysis with correspon ding UML examples.

• FEATUREENVY: Based on a class diagr a m alone,

a FEATUREENVY candidate can not be spotted,

since the UML does not provide elements to mo -

del d e penden cies between features. The relations-

hips (including dep e ndencies) between c la sses do

not indicate a FEATUREENVY. However, a se-

quence diagram reﬂecting the method calls trig-

gered b y the candidate metho d d uring o ne or mul-

tiple usage scenarios might illustrate that more fo-

On using UML Diagrams to Identify and Assess Software Design Smells

417

DeﬁcientEncapsulation

a1()

a2()

a3()

:B :A

sd 1

a3()

:C :A

sd 2

a1()

a3()

Design Smell Structural Scope Behavioral ScopeExemplary Class Diagram Exemplary Sequence Diagram

a2()

Candidate attributes

and/or methods

(a2()) with owning class

(indicating that feature

is publicly available)

All interactions with

class of candidate

attribute/method

(indicating that a2()

is not used by other

classes)

Figure 2: Selected ENCAPSULATION smells with exemplary UML class and sequence diagrams reﬂecting the str uctural and

behavioral design scope and smell symptoms (see Tab. 1). Smell symptoms are highlighted in red.

Multipa

lati

Design Smell Structural Scope Behavioral ScopeExemplary Class Diagram Exemplary Sequence Diagram

b1()

b2()

b3()

:C :A

sd 2

a1()

a2()

Candidate class (B)

with subclasses

(and superclasses)

tions of

subclasses (here A)

(indicating that

features of candidate

class B are not used)

e classes A and

B (with features) and

subclasses (indicating

that variability of

subclasses only in terms

of attributes)

e class

(inher

class C)

classes

(indicating a deep

hierarchy)

e class

(inher

class A)

classes

(indicating multiple

hierarchy paths

to superclass C)

Figure 3: Selected HIERARCHY smells with exemplary UML class and sequence diagrams reﬂecting the structural and beha-

vioral design scope and smell symptoms (see Tab. 1). Smell symptoms are highlighted in r ed.

reign method s are used than by the own class and

can in dicate a FEATUREENVY.

• DATACLASS: A class diagram can show that a

class provides no methods at all. In a ddition, a

sequence diagram can indicate DATACLASS can-

didates which have methods that do not access the

own data.

• CYCLICALLYDEPENDENTMODULARIZATION:

Relations (e.g., associations and dependencies)

can indicate a circula r dependency (dir ect or

transitive) b e tween classes. Also in sequence

diagrams, these dependencies can be illustrated

via co rresponding messages between lifelines.

• MESSAGECHAIN: Chains of relationships bet-

ween c la sses in class diagrams do not indicate a

MESSAGECHAIN smell. In contrast, messages in

sequence diagrams can obviously illustrate them

(including the ir depth level).

Preliminary Findings on UML-based Represen-

tability of Design Smells. The examples shown

above illustrate that all selected design smells can

be represented and ide ntiﬁed by combining UML

class an d sequence diagrams. By only reviewing

UML class diagrams, most of the smell kinds are

not identiﬁable (with exception of most HIERARCHY

smells). In particular, in order to express relations-

hips be tween classes, th e UML provides different

kinds of

Relationship

, such as

Association

and

Dependency

, see (Object Management Group, 2015).

In contrast, it does not allow for expressing dependen -

cies between

Operation

s (in terms of method-call

dependencies). For identifying dependency-related

symptoms (especially relevant for MODULARIZA-

TION, ABSTRACTION, and also ENCAPSULATION

SMELLS), the seq uence diagrams can provide additio-

nal information by representing method/featu re calls

in terms of sequences of (mutual)

Message

s, which

allows for investigating the details of method-call de-

pendencies, e.g., for identifyin g method-based CY-

CLICDEPENDENCIES. A pr erequisite for this is that

the UML seq uence diagrams reﬂect actual/intended

ICSOFT 2018 - 13th International Conference on Software Technologies

418

A CB

:A :B :C

MessageChain

A CB

DataClass

:A :B :C

FeatureEnvy

A CB :A :B :C

CyclicDependency

:A :B :C

A CB

Design Smell Structural Scope Behavioral ScopeExemplary Class Diagram Exemplary Sequence Diagram

Candidate method

(c2()) and its

owning class

as well as used

features with classes

c2()

All method calls t

andidate method

c2() dur

scenario (indicating that

more foreign features are

used than by own class)

e class (B) with

ures)

and the classes usin

the data (indicating that

no methods exist)

All interactions of

the candidate class (B)

(indicating that B uses no

methods for operating

on own data)

All classes with

featur

(indicating structural

dependencies; B and C

direct, A and C indirect)

All inter

ethod calls

between t

classes a usa

scenario (indicating cyclic

call dependencies, B and

C as well as A and C)

d called

methods in the chain

with own

All method calls t

(dir

d tra

didate method a2()

c us

scenario (indicating a

chain with depth of 3)

Figure 4: Selected MODULARIZATION smells with exemplary UML cl ass and sequence diagrams reﬂecting the structural and

behavioral design scope and smell symptoms (see Tab. 1). Smell symptoms are highlighted in red.

usage scenarios. Moreover, class diagra ms seem suf-

ﬁcient for identifying most of HIERARCHY smells

(via the

Generalization

relationship).

3.2 Further Identiﬁcation and

Assessment Chall enges

In the f ollowing, we reﬂect on selected further chal-

lenges f or UML-based smell identiﬁcation and asses-

sment.

Locating the Relevant Design Context. Manually

created and maintained UML diagrams often lack

with regard to up -to-dateness a nd consistency with

the documented software system . In contrast, (auto-

matically) reverse-engineered UML diagrams (esp e-

cially by applying dyna mic analysis techniques) come

with the pr oblem of large model size and a high de-

tail level which impedes c omprehending the diagram

(Fern´andez-S´aez et al., 2015). For this reason, in re-

cent years, different techniques for interactively ex-

ploring or conﬁguring the scope of the diag rams have

been proposed, see, e.g., (Bennett et al., 2008; Ha -

endler et al., 2015). Independent from the method of

creating the de sig n documentation, the challenge re-

mains to locate the relevant part of a design diagram

(design scope, see above), esp ecially in case of asses-

sing a given smell candidate.

Distinctiveness of Smells. Another aspect is the

distinctiveness of the symptoms represented via the

UML diagrams. As seen by the examples in Section

3, the diagrammatic representation alone would pre-

sumably not allow to identify an d to distinguish spe-

ciﬁc kinds of smells, or even false positives. For in-

stance, the examples of UML class diagrams repre-

senting FEATUREENVY, CYCLICDEPENDENCY and

DATACLASS smells have a very similar appearance.

However, it becomes c lear that a UML-based visuali-

zation not in every case can suppo rt in comprehen ding

the an a lyzed issue.

4 RELATED WORK

To the best of our knowledge, so far there is no rese-

arch addressing the speciﬁcation or identiﬁcation of

software design smells via UML dia grams. However,

closely related is research aiming at modeling code

smells and corresponding refactorings in UML dia-

grams:

The mo del-smell detector EMF Refactor, see, e.g.,

(Arendt et al., 2009), provides several techniques for

assuring the model quality of Ecore and UML2 mo -

dels. In particular, the tool provides 23 quality me-

trics for Ecore mode ls which cover 3 kinds of smells

for Ecore models and 22 correspon ding refactoring

techniques. For UM L2 models, it provides in total

107 metrics which cover 27 model smells. The ad-

dressed smells largely do not r eﬂect software-design

issues as reﬂected in this paper (see Section 2). The

study reported in (Arendt a nd Taentzer, 2010 ) focu-

ses on model smells for the early stage of a model-

based software-development process. Among othe r

On using UML Diagrams to Identify and Assess Software Design Smells

419

things, Arendt et al. present a catalog with 17 UML

model sm e lls consisting of a description, detection

techniques, refactorings, quality characteristics af-

fected, and an example represented in terms of a UML

diagram. (Rojas et al., 2017) analyze the effects of

creating and refactoring smells in conceptual models

(based on smell deﬁnitions by EMF Refactor) on the

technical debt of the underlying source code measu-

red b y applying SonarQu be (Campb ell and Papape-

trou, 2013). They m ainly focus on the refactoring

effort in c orrelation with the measured TD. Within

this, they also map correlations between smells in

Java source code an d model smells in UML class di-

agrams. However, both studies do not ad dress design

smells as described in this paper and do not reﬂect on

their r e presentability.

Moreover, approach e s are related tha t evaluate the

impact of applying UM L diagrams fo r the localization

of design defects and for performing software mainte-

nance activities in general. (Laitenberger et al., 2000)

investigate in a c ontrolled experiment how design de -

fects can be located via UML diagrams. As a result,

they provide m appings betwee n defects and diagram

types. However, they address defects that can not be

categorized as design smells a nd pursue a more gene-

ral approach based on model quality attributes (such

as completeness or consistency). For instance, (Aris-

holm et al., 2006; Scanniello et al., 2018) investiga-

ted in empirical stud ies that the availability of UML-

based design documentation enhances th e compre-

hensibility of the system sou rce code, especially with

regard to performing complex maintenance tasks.

As a complement to both groups of research, we

present a conceptu al investigation of the applicabi-

lity of UML diagrams f or identifying software design

smells.

5 DISCUSSION

In this position paper, w e report on work-in-progress

and present results of an investigation on the appli-

cability of UML2 diagrams f or identifying and asses-

sing software design smells. The ana lysis has a c on-

ceptual and exploratory character. It provides a ﬁrst

systematization with preliminary results that de mand

for e mpirical evaluation w hich will be approache d in

future work.

We only focused on UML2 class an d sequence

diagrams because of their popularity in industry and

since they are most common for structural and beha-

vioral a spects respectively o n the design level. Ho-

wever, other diagram types of the UML2 such as

state charts, activity diag rams or component diagrams

might also serve as a basis for the identiﬁcation of

certain smell kinds, which should be investigated in

further research.

For the purpose of compreh ensibility, simple,

synthetic and syntactically reduced U ML diagram ex-

amples have been presented. Moreover, we focused

on an exemplary set of 14 software design smells with

representatives for each violated design pr inciple.

6 CONCLUSION

In this paper, we investigated whether UML2 c lass

and sequence diagram s provide the information nee-

ded for identifying and assessing 14 kinds of software

design smells. In particu lar, we analyz e d the smell

representability by cr eating synthetic diagram exam-

ples which reﬂect the minimal structural and beha-

vioral design context to include all system eleme nts

directly affected by the c orresponding smell. In addi-

tion, we discussed further challenges for UML-based

smell identiﬁcation and assessment. As a result of this

exploratory approach can be stated that all selected

kinds of software design smells with their symptoms

can be represented and identiﬁed b y combining UML

class and sequence diagrams. By using UML c la ss di-

agrams alone, only a f ew smell kinds are identiﬁable

(i.e. mostly HIERARCHY smells). However, the ex-

amples also illustrate that an identiﬁcation of design

smells or a distinction between th e different smells via

reviewing the UML diagrams provides some difﬁcul-

ties, since the d ia grammatic appearanc e of smells can

be partially very similar. Especially, it seems chal-

lenging to recognize patterns for identifying design

smells in UML diagrams, due to the various manife-

stations of smell symptoms.

This analysis represents a ﬁrst step to investigate

the possibilities of a UML-based smell evaluation.

For future work , we plan to validate the ﬁndings in

an empir ic a l setting by comparing the occurrence of

software design smells detected in source code with

their appea rance in co rresponding reverse-engineered

UML-based design documentation. Moreover, we

aim to develop an intelligent tutoring system (ITS)

for guiding software engineers in acquiring techni-

ques for assessing and refactoring design smells. For

decision support within the ITS for refactoring tasks,

we plan to provide reverse-engineered and tailorable

UML diagrams, also see (Haendler et al., 20 17).

ICSOFT 2018 - 13th International Conference on Software Technologies

420

REFERENCES

Arendt, T., Mantz, F., Schneider, L., and Taentzer, G.

(2009). Model refactoring in eclipse by LTK, EWL,

and EMF refactor: a case study. In Model-Driven Soft-

ware Evolution, Workshop Models and Evolution.

Arendt, T. and Taentzer, G. (2010). UML model smells

and model refactorings in early software development

phases. Universitat Marburg.

Arisholm, E., Briand, L. C., Hove, S. E., and Labiche, Y.

(2006). The impact of UML documentation on soft-

ware maintenance: An experimental evaluation. IEEE

Transactions on Software Engineering, 32(6):365–

381.

Bennett, C., Myers, D., Storey, M.-A., German, D. M.,

Ouellet, D., Salois, M., and Charland, P. (2008). A

survey and evaluation of tool features for understan-

ding reverse-engineered sequence diagrams. Journal

of Software: Evolution and Process, 20(4):291–315.

Campbell, G. and Papapetrou, P. P. (2013). SonarQube in

action. Manning Publications Co.

CoderGears (2017). JArchitect. [last access: June 8, 2018].

Fernandes, E., Oliveira, J., Vale, G., Paiva, T., and Figuei-

redo, E. (2016). A review-based comparative study

of bad smell detection tools. In Proceedings of the

20th International Conference on Evaluation and As-

sessment in Software Engineering, page 18. ACM.

Fern´andez-S´aez, A. M., Genero, M., Chaudron, M. R ., Cai-

vano, D., and Ramos, I. (2015). Are forward designed

or reverse-engineered UML diagrams more helpful for

code maintenance?: A family of experiments. Infor-

mation and Software Technology, 57:644–663.

Fontana, F. A., Braione, P., and Zanoni, M. (2012). Auto-

matic detection of bad smells in code: An experimen-

tal assessment. J. Object Technology, 11(2):5–1.

Fontana, F. A., Dietrich, J., Walter, B., Yamashita, A., and

Zanoni, M. (2016). Antipattern and code smell false

positives: Preliminary conceptualization and classiﬁ-

cation. In Proc. SANER’16, volume 1, pages 609–613.

IEEE.

Fowler, M., Beck, K., Brant, J., Opdyke, W., and Roberts,

D. (1999). Refactoring: improving the design of exis-

ting code. Addison-Wesley Professional.

Gamma, E., Helm, R., Johnson, R., and Vlissides, J.

(1995). Design Patterns: Elements of Reusable

Object-oriented Software. Addison-Wesley L ongman

Publishing Co., Inc., Boston, MA, USA.

Haendler, T., Sobernig, S., and Strembeck, M. (2015). Deri-

ving tailored UML interaction models from scenario-

based runtime tests. In International Conference on

Software Technologies, pages 326–348. Springer.

Haendler, T. , Sobernig, S., and Strembeck, M. (2017). To-

wards triaging code-smell candidates via runtime sce-

narios and method-call dependencies. In Proceedings

of the XP2017 Scientiﬁc Workshops, pages 1–9. ACM.

hello2morrow (2017). Sonargraph. [last access: June 8,

2018].

Kruchten, P., Nord, R. L., and Ozkaya, I. (2012). Techni-

cal debt: From metaphor to theory and practice. Ieee

software, 29(6):18–21.

Laitenberger, O., Atkinson, C., Schlich, M., and El Emam,

K. (2000). An experimental comparison of reading

techniques for defect detection in UML design docu-

ments. Journal of Systems and Software, 53(2):183–

204.

Moha, N., Gueheneuc, Y.-G., Duchien, L., and Le Meur,

A.-F. (2010). Decor: A method for the speciﬁcation

and detection of code and design smells. IEEE Tran-

sactions on Software Engineering, 36(1):20–36.

Mohagheghi, P., Dehlen, V., and Neple, T. (2009). Deﬁni-

tions and approaches t o model quality in model-based

software development–a review of literature. Informa-

tion and Software Technology, 51(12):1646–1669.

Object Management Group (2015). Uniﬁed Modeling Lan-

guage (UML), Superstructure, Version 2.5.0. [l ast

access: June 8, 2018].

Panichella, S., Arnaoudova, V., Di Penta, M., and Antoniol,

G. (2015). Would static analysis tools help developers

with code reviews? In Proc. SANER’15, pages 161–

170. IEE E.

Ribeiro, L. F., de Freitas Farias, M. A., Mendonc¸a, M. G.,

and Sp´ınola, R. O. (2016). Decision criteria for the

payment of technical debt in software projects: A sys-

tematic mapping study. In I CEIS (1), pages 572–579.

Rojas, G., Izurieta, C., and Grifﬁth, I. (2017). Toward

technical debt aware software modeling. In IEEE-

ACM Ibero American Conference on Software Engi-

neering, CibSE, pages 22–35.

Scanniello, G., Gravino, C., Genero, M., Cruz-Lemus, J. A.,

Tortora, G., Risi, M., and Dodero, G. (2018). Do

software models based on the UML aid in source-

code comprehensibility? aggregating evidence from

12 controlled experiments. Empirical Software Engi-

neering, pages 1–39.

Sharp, R. and Rountev, A. (2005). Interactive explora-

tion of UML sequence diagrams. In Visualizing Soft-

ware for Understanding and Analysis, 2005. VIS-

SOFT 2005. 3rd IEE E International Workshop on, pa-

ges 1–6. IE EE.

Stroulia, E. and Syst¨a, T. (2002). Dynamic analysis for re-

verse engineering and program understanding. ACM

SIGAPP Applied Computing Review, 10(1):8–17.

Suny´e, G., Pollet, D., Le Traon, Y., and J´ez´equel, J.-M.

(2001). Refactoring UML models. In International

Conference on the Uniﬁed Modeling Language, pages

134–148. Springer.

Suryanarayana, G., Samarthyam, G., and Sharma, T.

(2014). Refactoring f or software design smells: ma-

naging technical debt. Morgan Kaufmann.

Tempero, E., Gorschek, T., and Angelis, L. (2017). Bar-

riers to refactoring. Communications of the ACM,

60(10):54–61.

Tsantalis, N. (2017). JDeodorant. [last access: June 8,

2018].

ZEN PROGRAM ( 2017). NDepend. [last access: June 8,

2018].

On using UML Diagrams to Identify and Assess Software Design Smells

421