Ontology-based Analysis of Game Designs for Software Refactoring

Thorsten Haendler and Gustaf Neumann

Institute for Information Systems and New Media, Vienna University of Economics and Business (WU), Austria

Keywords:

Software Refactoring, Gamiﬁcation, Serious Games, Game Design, Game Analysis, Domain Ontology,

Software Engineering Education and Training.

Abstract:

Acquiring practical competences in computer programming and software engineering is challenging. Software

refactoring, in particular, is considered an important and useful quality-assurance technique, but due to the

perceived difﬁculties and risks of performing it, often neglected in practice. Still, it received little attention

by software engineering education and training so far. Games are a popular means for fostering motivation as

well as mediating and improving practical competences by providing an enjoyable and playful environment.

However, for instructors it is challenging to develop and apply game designs that address certain learning

objectives, which is important for integrating the game into existing or planned learning and training paths,

e.g., in the framework of university courses or training units for (experienced) software developers. In this

paper, we propose an ontology that aims to support the analysis and design of games in the ﬁeld of software

refactoring. We apply a structured process for creating a unifying domain ontology bridging core concepts

from three related ﬁelds, i.e. game design (a), software refactoring (b), and competence management (c). The

resulting ontology is then represented as a meta-model in terms of a UML class diagram and reﬂects concepts

important for refactoring-game designs. We describe ontology-based options for game design and illustrate

the use of the ontology by analyzing existing refactoring-gaming approaches. In addition, we reﬂect applying

the ontology for reasoning about novel game designs and discuss further potential of the approach.

1 INTRODUCTION

Acquiring practical competences in computer pro-

gramming and software engineering is challenging,

since it requires in-dept knowledge and experience.

Software refactoring, in particular, is considered an

important and useful quality-assurance technique to

reduce a system’s maintenance costs by improving

its internal quality (Kruchten et al., 2012), but which

is difﬁcult to acquire for software developers. Due

to the perceived difﬁculties and risks of perform-

ing it, refactoring is often avoided in practice (Tem-

pero et al., 2017). Even though textbooks with rules

and best practices are available (Fowler et al., 1999;

Suryanarayana et al., 2014), they can barely medi-

ate the skills for actually reviewing larger code bases

for refactoring opportunities or performing non-trivial

refactorings. Still, it received little attention by soft-

ware engineering education and training so far; see,

e.g., (Haendler et al., 2019).

Games are in general a popular means for fos-

tering motivation as well as mediating and improv-

ing practical competences by providing a playful en-

vironment (Hamari et al., 2014). In recent years,

several approaches for serious gaming and gamiﬁca-

tion in programming and software engineering have

been proposed; for an overview, see (Pedreira et al.,

2015; Miljanovic and Bradbury, 2018; Alhammad

and Moreno, 2018). In turn, in the ﬁeld of software

refactoring, so far only a few gaming approaches can

be identiﬁed; see, e.g., (Raab, 2012; Elezi et al., 2016;

Haendler and Neumann, 2019).

However, for instructors there are no guidelines or

tools helping to develop and apply game designs that

address certain learning objectives, which is impor-

tant for integrating the game into existing or planned

learning and training paths, e.g., university courses,

or training units for software developers. In order to

be able to systematically design and develop games

for refactoring with the purposes of addressing certain

practical competences or of fostering the motivation

to perform refactorings, the conceptual ﬁeld needs to

be systematically structured.

In this paper, we propose an approach for the de-

velopment of an ontology for designing and analyz-

ing software-refactoring games. For this purpose, we

reuse and combine relevant concepts from three re-

lated domain areas, i.e., game design (a), software

Haendler, T. and Neumann, G.

Ontology-based Analysis of Game Designs for Software Refactoring.

DOI: 10.5220/0007878300240035

In Proceedings of the 11th International Conference on Computer Supported Education (CSEDU 2019), pages 24-35

ISBN: 978-989-758-367-4

refactoring (b), and competence management (c). In

particular, it was useful, to break these domain areas

further down to 5 different domains. The resulting do-

main ontology is documented in terms of a UML class

diagram and aims to support in better understanding

the concepts for designing games. For this purpose,

besides the concepts and concept relations, also de-

sign options in terms of ontology instances are de-

scribed in detail. This way, the ontology represents a

step towards the structured design of games for soft-

ware refactoring. The applicability of the ontology

is illustrated via the ontology-based analysis of three

existing game designs for software refactoring. In ad-

dition, we also reﬂect how the ontology can be used

to develop novel game designs. This paper provides

the following contributions:

• development of a domain ontology for represent-

ing relevant concepts for game designs in software

refactoring.

• documentation of the refactoring-game ontology

as a meta-model in terms of a UML class dia-

gram including a description of game-design op-

tions (i.e., ontology instances).

• ontology-based analysis of (exemplary) existing

refactoring-game designs.

Fig. 1 gives a high-level overview of the approach.

For developing a domain ontology for software-

refactoring games, relevant concepts of three related

domain areas (i.e., software refactoring, competence

management, and game design) are reused, combined

and extended (where necessary).

The resulting ontology can be seen as an abstrac-

Game Design

Development

of novel games

Game Design

«instances of»

Analysis of

existing games

Competence

Prerequisite

Competence

Actual

Competence

Target

Competence

Level

Learner

Application

Cognitive Level

Knowledge

Comprehension

Creation

Evaluation

Analysis

Instructor

Information

Reward

Achievement

Game

Leader Board

View

Game Level

Rule

Action

Mission

Punishment

Player

IndividualTeam

Interaction

Collaboration Competition

Feedback

Decision

Support

Technical

Debt

(Software)

System

Refactoring

Candidate

Smell

Category

Analysis Tool

Quality

Analyzer

Refactoring

Step

Code Artifact

Investigation

Activity

Code Modiﬁcation

Activity

Maintenance

Activity

Engineer

Symptom

Technical

Debt Item

Smell

Move

Test

Framework

Metric

GUI

Hint

Evaluation

Analysis

Reused (or Modiﬁed)

Concept

Subdomain

Game Design

Rule

Task

Time

Constraint

Time

Measurement

Assessment

Learning Unit

Aesthetic

Aspect

Mechanics

Dynamics

Aesthetics

SE Tool

Task

Editor

Goal

+ +

Extended

Concept

Game Design

Competence

Management

Managing

Technical Debt

Levels of Learning

Objectives

Software

Maintenance

oriented to and partially reused from

(Hunicke et al. 2004,García et al. 2017)

oriented to and partially reused from

(Paquette 2007)

oriented to and partially reused

from (Kitchenham et al. 1999)

oriented to and partially reused from

(Avgeriou et al. 2016)

reused from

(Bloom et al. 1956)

Game Type

0..1

* *

0..1

performs

nes

input

output

performs

based on

executes

relates to

Activity

0..1

processes

performs

uses

based on

measures

outcomes

presents

integrates

provides

applies

performs

usesbased on

Further diagram notations compliant

with UML

Legend

removes

Game-Design

Concepts

Concepts of Competence

Management

Refactoring

Concepts

Refactoring-Game Ontology

Figure 1: Conceptual overview of developing a domain on-

tology for analysis and design of refactoring games (for the

resulting ontological model, see Fig. 2).

tion of concrete refactoring-game designs. Existing

game designs (i.e., ontology instances) can be ana-

lyzed and classiﬁed by the ontology. Moreover, the

ontology can support in reasoning about the develop-

ment of novel game designs.

Structure. The remainder of this paper is structured

as follows. In Section 2, we reﬂect on background

(and related work) in software refactoring, games for

programming (and refactoring in particular), and the

use of ontologies (for game design). Section 3 de-

tails the process of creating the domain ontology of

game designs for software refactoring. In Section 4,

we present the resulting ontological model and de-

scribe design options for its instantiation. Section 5

illustrates, how the ontology can be applied for ana-

lyzing and classifying existing gaming approaches. In

Section 6, we reﬂect on applying the ontology for rea-

soning about designing novel approaches and discuss

further potential. Section 7 concludes the paper.

2 BACKGROUND AND RELATED

WORK

2.1 Refactoring and its Challenges

Refactoring is an important quality-assurance tech-

nique that helps improving the code quality regard-

ing its maintainability by restructuring the source

code without changing the system’s external behav-

ior (Opdyke, 1992; Fowler et al., 1999). Despite

considered important and helpful, refactoring is of-

ten neglected in practice (Tempero et al., 2017). The

refactoring workﬂow can be roughly structured into

the following tasks:

(1) identifying refactoring candidates (a.k.a. opportu-

nities) in terms of smells or technical-debt items

(Kruchten et al., 2012) and

(2) planning and performing the refactorings step se-

quences (Fowler et al., 1999).

In this process, software developers are supported by

several analysis tools, such as quality analyzers, e.g.,

SonarQube (Campbell and Papapetrou, 2013), and

refactoring tools, e.g., JDeodorant (Tsantalis et al.,

2008) (for identifying refactoring candidates such as

smells or for performing refactorings), or test frame-

works, e.g., the XUnit framework, for automated run-

time regression testing (in order to ensure that no er-

rors have been introduced). Despite these advances

regarding tool support, developers still perceive dif-

ﬁculties in the refactoring process and a lack of ade-

quate tool support, which often prevents them from

Ontology-based Analysis of Game Designs for Software Refactoring

performing refactoring in practice (Tempero et al.,

2017). A way to address these challenges can be seen

in fostering developers’ motivation and practical com-

petences in refactoring.

2.2 Game Designs for (Training)

Programming

In recent years, several game designs for training

skills in programming and software engineering have

been proposed; for serious gaming, see, e.g., (Mil-

janovic and Bradbury, 2018), for gamiﬁcation, (Pe-

dreira et al., 2015; Alhammad and Moreno, 2018).

However, so far, only a few games and game designs

exist for software refactoring in particular. These ap-

proaches will be analyzed in Section 5. A goal of this

paper is to identify design options based on ontologi-

cal concepts for creating and analyzing game designs.

For this purpose, we adopt and reuse existing frame-

works, such as the MDA framework which structures

game design through the perspectives of mechanics,

dynamics and aesthetics (Hunicke et al., 2004). In

addition to this, design options also depend on condi-

tions and aspects in the application areas and purposes

of the game, e.g., the ﬁelds of software refactoring as

well as of learning and training.

2.3 Ontologies

Originating from the philosophical discipline of meta-

physics, an ontology represents a structure of entities

with the purpose of organizing knowledge (in a cer-

tain domain) and managing complexity. In contrast

to automatically processed ontologies such as web

knowledge graphs (Paulheim, 2017), visually repre-

sented ontologies for human consumption need to be

manageable in size and are often less formally spec-

iﬁed. For example, in information systems research

and practice, ontological models often are understood

as conceptual models with the objective to share a

common understanding of structure of and relation-

ships between concepts in a certain domain (Guiz-

zardi et al., 2002). Concepts are often represented

as classes related to other classes, e.g., in terms of

a UML class diagram (Object Management Group,

2015).

3 ONTOLOGY DEVELOPMENT

In developing the ontology, we are guided by the

structured process proposed by (Noy et al., 2001) con-

sisting of seven distinguished steps from deﬁning the

scope of the ontology, via considering the reuse of

existing ontologies to deﬁning classes and class re-

lations. In Section 3.1, we describe the scope of the

domain ontology and reﬂect the ontologies identiﬁed

and considered for reuse. In Section 3.2, we explain

how the classes and relations have been deﬁned and

what kinds of aspects had to be extended. The result-

ing ontology is presented in Section 4.1 and the op-

tions for creating ontological instances are elaborated

in Section 4.2. In Section 5, the ontology is applied to

analyze existing gaming approaches.

3.1 Ontology Scope and Reuse of

Existing Ontologies

The scope of the ontology is deﬁned by the question:

How to design games for imparting practical compe-

tences for software refactoring? (see Section 1).

For this purpose, concepts from the following

three ﬁelds are relevant:

• Game Design: (as the interaction environment),

• Software Refactoring: (as the technical domain),

as well as

• Competence Management: (since the games

aim at mediating certain competences to users).

In these three ﬁelds, already ontologies and/or tax-

onomies are established that can be reused as ex-

plained in the following.

Game Design. The MDA framework for structur-

ing the design concepts from the three perspectives

mechanics, dynamics and aesthetics is quite popular

and represents a quasi-standard for game design (Hu-

nicke et al., 2004). In particular, mechanics comprise

the basic game components such as actions performed

by the player and the rules. The dynamics represent

the run-time behavior of the game including feedback

mechanisms and user interaction. Aesthetics, ﬁnally

reﬂect (the more abstract) aspects of emotional and

motivational responses evoked in the player (Hunicke

et al., 2004). However, the framework reﬂects the

important perspectives for game design, but does not

represent the concepts in detail in terms of a domain

ontology. (Garc

ıa et al., 2017) builds upon these per-

spectives and reﬁnes them by presenting a framework

for the introduction of gamiﬁcation in software engi-

neering, which also includes a structured domain on-

tology. With the focus on gamiﬁcation in software

engineering, i.e., how software-engineering tools (ap-

plied in practice) can be extended by gamiﬁcation el-

ements, multiple concepts are also related to games in

software refactoring (see Section 3.2). We combine

both frameworks to cover a large part of concepts of

game design.

CSEDU 2019 - 11th International Conference on Computer Supported Education

Software Refactoring. We have identiﬁed two pop-

ular ontologies and concept formations in the ﬁeld of

software refactoring. First, refactoring can be classi-

ﬁed as a preventive maintenance activity. The ontol-

ogy of software maintenance proposed by (Kitchen-

ham et al., 1999) structures important software-

maintenance activities and in particular covers differ-

ent tasks. Second, from the perspective of techni-

cal debt management, the candidates for refactoring

(e.g., code smells) are kinds of technical debt items.

The ontology proposed by (Avgeriou et al., 2016) rep-

resents the concepts relevant for managing technical

debt. A combination of both covers some important

concepts in the ﬁeld of refactoring.

Competence Management. For competence man-

agement (and learning objectives), popular ontologies

and/or taxonomies can be found. First, Paquette pro-

vides an ontology for competence management (Pa-

quette, 2007). In this work, competences are special-

ized into actual, prerequisite and target competences

(a.k.a. learning objectives). Complementing this on-

tology, Bloom’s taxonomy (Bloom et al., 1956) pro-

vides details on complexity levels of (cognitive) learn-

ing objectives in terms of a hierarchical order of six

levels. In (Krathwohl, 2002), a revised version has

been proposed, which is applied for our ontology. The

taxonomy is especially popular for specifying (levels

of) competences in engineering education and train-

ing (Britto and Usman, 2015; Masapanta-Carri

on and

Vel

azquez-Iturbide, 2018).

3.2 Deﬁning Classes and Relations

The ﬁve ontologies from different domains identiﬁed

in Section 3.1 cover multiple concepts in the ﬁeld of

(educational) software-refactoring games. In the next

step, we extracted the concepts relevant for this pur-

pose and checked them for synonyms and homonyms,

for further overlaps and possible connection points

between the concepts via relationships (such as user

roles, kinds of actions or artifacts). While deﬁn-

ing classes, class hierarchies and relationships be-

tween classes, it became obvious that a few exten-

sions would be necessary. In particular, refactoring-

related concepts (such as smells, analysis and analysis

tools), basic educational concepts (such as learner, in-

structor, task, activity, learning unit, and evaluation)

as well as further concepts oriented to game design

(such as move, assessment, user interaction and feed-

back) have been extended in order to cover the con-

ceptional scope for refactoring-game design. Details

on these extensions are presented in Section 4.

4 REFACTORING-GAME

ONTOLOGY

For documenting the ontological concepts for

refactoring-game designs, we (1) structure the con-

cepts in terms of a meta-model (see Section 4.1) and

(2) reﬂect on options for instantiating the game ontol-

ogy (see Section 4.2).

4.1 Ontology Representation

The domain ontology resulting from the applied de-

velopment process (see Section 3) is documented as a

meta-model in terms of a class diagram of the Uni-

ﬁed Modeling Language (UML2) (Object Manage-

ment Group, 2015). Fig. 2 depicts the resulting on-

tology.

The class diagram allows for organizing the

identiﬁed concepts as classes and their relationships

in terms of generalizations and kinds of associations,

see (Object Management Group, 2015). The 67 con-

cepts covered by the domain ontology are (visually)

structured into the ﬁve sub-domains (see

 to

 in

Fig. 2) identiﬁed for containing concepts relevant for

game designs in software refactoring (see Table 1).

Table 1: Ontology sub-domains in Fig. 2.

No Sub-Domain Reference

 Game Design (Hunicke et al., 2004; Garc

ıa

et al., 2017)

 Competence Management (Paquette, 2007)

 Levels of Learning Objec-

tives

(Bloom et al., 1956)

 Software Maintenance (Kitchenham et al., 1999)

 Managing Technical Debt (Avgeriou et al., 2016)

The sub-domains are connected via several links be-

tween concepts, e.g., in terms of relationships. Mul-

tiple concepts (classes) and relationships have been

reused (or slightly modiﬁed regarding name or rela-

tionships for the purpose of the new contextualiza-

tion). A few concepts (marked with dashed border

and plus sign) have been added in order to (1) al-

low concept combination and/or (2) provide concepts

that are particularly important for game design in soft-

ware refactoring, but are not covered by the selected

reused (sub-) domain ontologies. The notations ap-

plied in the diagram are compliant with UML, e.g.,

class names in italic (such as Competence in

 in

Fig. 2) indicate abstract concepts that do not allow in-

stantiation directly, but via sub-classes.

In the following, hubs in the diagram (see Fig. 2)

with connections between key concepts from multiple

The ontological model is also available for download as

SVG/XML ﬁle from http://refactoringgames.com/ontology

Ontology-based Analysis of Game Designs for Software Refactoring

Competence

Prerequisite

Competence

Actual

Competence

Target

Competence

Level

Learner

Application

Cognitive Level

Knowledge

Comprehension

Creation

Evaluation

Analysis

Instructor

Information

Reward

Achievement

Game

Leader Board

View

Game Level

Rule

Action

Mission

Punishment

Player

IndividualTeam

Interaction

Collaboration Competition

Feedback

Decision

Support

Technical

Debt

(Software)

System

Refactoring

Candidate

Smell

Category

Analysis Tool

Quality

Analyzer

Refactoring

Step

Code Artifact

Investigation

Activity

Code Modiﬁcation

Activity

Maintenance

Activity

Engineer

Symptom

Technical

Debt Item

Smell

Move

Test

Framework

Metric

GUI

Hint

Evaluation

Analysis

Reused (or Modiﬁed)

Concept

Subdomain

Game Design

Rule

Task

Time

Constraint

Time

Measurement

Assessment

Learning Unit

Aesthetic

Aspect

Mechanics

Dynamics

Aesthetics

SE Tool

Task

Editor

Goal

+ +

Added

Concept

Game Design

Competence

Management

Managing

Technical Debt

Levels of Learning

Objectives

Software

Maintenance

oriented to and partially reused from

(Hunicke et al. 2004,García et al. 2017)

oriented to and partially reused from

(Paquette 2007)

oriented to and partially reused

from (Kitchenham et al. 1999)

oriented to and partially reused from

(Avgeriou et al. 2016)

reused from

(Bloom et al. 1956)

Game Type

0..1

* *

0..1

performs

nes

input

output

performs

based on

executes

relates to

Activity

0..1

processes

performs

uses

based on

measures

outcomes

presents

integrates

provides

applies

performs

usesbased on

Further diagram notations compliant

with UML

Legend

removes

Figure 2: Domain ontology for game design in software refactoring combining concepts from related sub-domains.

sub-domains are described in detail as well as the ex-

tensions by new concepts are argued. For further de-

tails on reused concepts not explained in detail, please

consult the research papers that have introduced the

corresponding sub-domain ontologies (Table 1).

User Roles and Competences. A user of refactor-

ing games acts in three roles, i.e., ﬁrst, in the role

of a Player that performs game moves and aims

at accomplishing the goal of the game (see

 in

Fig. 2), then in the role of a Learner that performs

training Activities (that optionally base on a Task)

and aims at acquiring and improving their Actual

Competences (in software refactoring; see

), and

ﬁnally in the role of an Engineer that performs refac-

toring activities or, in general, maintenance-related

activities (Kitchenham et al., 1999) (see

). This

way, the player can be seen as a kind of learner

and engineer (i.e. super-classes of player). Be-

sides these user roles, moreover an Instructor de-

ﬁnes tasks that are oriented to certain Prerequisite

Competences (necessary to perform the activity) and

aim at mediating certain Target Competences (i.e.,

learning objectives) to the learner. Each kind of

Competence can be characterized by the complex-

ity Levels, i.a., the Cognitive Level; see (Bloom

et al., 1956) and

 in Fig. 2.

User Activities and Interaction. While playing a

game, a user performs Actions that are on the one

hand part of a game Move (from a gaming perspec-

tive, see

 in Fig. 2) and on the other hand part

of training Activity (optionally) based on a Task

set by an Instructor(from learning perspective, see

). Moreover, in the context of software refactor-

ing, an action can be a Maintenance Activity that

can be expressed as an Investigation Activity or

a Code Modification Activity (e.g., in terms of

a concrete Refactoring Step, see

; in (Kitchen-

ham et al., 1999) deﬁned as enhancement and more

speciﬁc as changed implementation). A Player

can be an Individual or a Team (see

). Each

player can be part of Interactions between multi-

ple players, which can express as Collaboration or

Competition. This way, for instance, also competi-

tions between teams can be captured.

Artifacts and Information. Artifacts (such as

the software system’s source Code, test speciﬁcation

or documentation) are used as input or output of

Actions (e.g., Maintenance Activity) performed

by users (see

 in Fig. 2). Training- and game-play-

related artifacts are represented by Views (from tech-

nical perspective a.k.a. widgets (Garc

ıa et al., 2017))

such as Editors or Leaderboards (see

) . The

views also present other kind of Information, e.g.,

in terms of Decision Support for supporting users

in refactoring activities (such as Hints, e.g., the lo-

CSEDU 2019 - 11th International Conference on Computer Supported Education

cation of a refactoring candidate) or in terms of other

Feedback to user activities such as the accomplished

Achievement (e.g., expressed as Rewards via badges

or points).

Smells and Analysis. Each Refactoring

Candidate (a.k.a. refactoring opportunity) can

be seen as a Technical Debt Item that is part of a

System’s Technical Debt; see

 in Fig. 2 and for

further details, e.g., (Kruchten et al., 2012; Avgeriou

et al., 2016)). Among others, Smells are speciﬁc

refactoring candidates that can be allocated to a

certain Smell Category (such as code or architec-

ture smells). A refactoring candidate (e.g., a smell)

can be removed via one ore multiple Refactoring

Steps (see

). Each debt item manifests via certain

Symptoms (Fowler et al., 1999) that are based on

(and can be measured via) corresponding Metrics

. These metrics can be used during Analysis

(e.g., for smell detection), which represents a kind

of Investigation Activity (see

). In general,

different kinds of analysis can be performed by

Analysis Tools, which are speciﬁc Software

Engineering (SE) Tools (see

 and

) such as

Quality Analyzers (identifying debt items such as

smells or measuring the systems technical debt, see,

e.g., (Fontana et al., 2012)) or Test Frameworks

(ensuring that no error has been introduced). The

concepts in the scope of smells and analysis tools

have been extended, since they are essential concepts

for the refactoring workﬂow, see, e.g., (Haendler and

Frysak, 2018). Further details on concrete tools are

provided in Section 4.2.

Evaluation and Assessment. The terms evaluation

and assessment are often used synonym. Also in

the ﬁeld of games and training/education, especially

with regard to programming exercises, the meanings

are manifold, since it can be seen from different per-

spectives with different purposes. For the purposes

of this ontology, we distinguish between the (auto-

mated) Assessment in the gaming context and the

Evaluation performed by the Instructor for mea-

suring the learner’s activity performance. In par-

ticular, an Assessment (see

 in Fig.2) measures

the Player’s Moves by executing the deﬁned Rules

of game play. In turn, an Evaluation is applied

to evaluate the outcomes of the learner’s activities

against the deﬁned task, e.g., in order to determine the

learner’s actual competences (see above and

). It

may be performed by the instructor alone or also sup-

ported by a tool-based Analysis (see above). A spe-

ciﬁc concept of Assessment is Time Measurement,

since many games in general require performing ac-

tions or moves in a given time frame (see associ-

ated class Time Constraint) or the time is a crucial

factor in competitions between multiple players (see

above).

Mechanics, Dynamics and Aesthetics. The iden-

tiﬁed concepts of game design can also be loosely

divided into the perspectives of the MDA frame-

work (Hunicke et al., 2004). For instance, Action,

Move, Rule, Goal as basic game elements can be

allocated to Mechanics (see

 in Fig.2). Dynam-

ics comprise all concepts directly impacting the run-

time behavior of the game, i.e., for instance the

kinds of Feedback and Decision Support as well

as the player Interaction. Aesthetics are expressed

in the game Mission associated to one or multiple

Aesthetic Aspects.

4.2 Ontology Instances and

Game-Design Options

Concrete game designs can be seen as instances of

the ontology (also see Fig. 1), while they differ in

terms of the concept values. By structuring options of

these values, e.g., in terms of possible enumerations,

a knowledge base can be built (Noy et al., 2001) that

can serve as foundation for analyzing and for design-

ing gaming approaches (see Sections 5 and 6). For

this purpose, we will examine the following aspects,

which are especially important for refactoring-related

games: competence levels for refactoring tasks, smell

types, analysis and assessment (including analysis

tools), options for decision support, aesthetic aspects

(w.r.t. the MDA framework (Hunicke et al., 2004)),

and game types. Instances of other (more generic)

concepts such as kinds of Views (e.g., bar charts, ac-

tivity feeds etc.) or kinds of Rewards (e.g., badges,

points etc.) are not in scope of this section. Explana-

tions on these can be found in research literature on

gamiﬁcation and/or game-based learning in general,

see, e.g., (Garc

ıa et al., 2017).

Refactoring Tasks and Competence Levels. From

the perspective of software developers, refactoring

can be basically distinguished into the two following

tasks (or steps; also see Section 2.1).

(A) identify and assess refactoring candidates, and

(B) plan and perform refactoring steps.

Table 2 provides descriptions on the competence lev-

els (see

 in Fig. 2) of these tasks according to

Bloom’s revised taxonomy of cognitive learning ob-

jectives (Krathwohl, 2002). Practical competences as

targeted by serious games or gamiﬁcation approaches

Ontology-based Analysis of Game Designs for Software Refactoring

Table 2: Competences in software refactoring (Haendler and Neumann, 2019) structured by levels of Bloom’s taxonomy of

cognitive learning objectives.

Level Competences related to identifying and assessing refactoring

candidates (A)

Competences related to planning and performing refactoring

steps (B)

(1) Knowledge Reading and remembering the documented knowledge on

rules/symptoms for identifying bad smells.

Reading and remembering the documented knowledge on rules

for planning and performing refactoring (steps).

(2) Comprehension Understanding the rules/symptoms for identifying bad smells. Understanding the rules for planning and performing refactoring

(steps)

(3) Application Identifying refactoring candidates (e.g., bad smells) according

to rules/symptoms (in small synthetic examples).

Performing corresponding refactoring steps (in small synthetic

examples).

(4) Analysis Analyzing the system’s source code and design as well as the

candidate’s structural and behavioral dependencies while iden-

tifying refactoring candidates (in larger code base).

Analyzing the system’s source code and design as well as the

candidate’s structural and behavioral dependencies while per-

forming corresponding sequences of refactoring steps (in larger

code base).

(5) Evaluation Comparing and prioritizing refactoring candidates (according to

applied paradigm, such as risk or relevance).

Comparing and selecting options/paths for performing the refac-

toring (steps).

(6) Creation Developing and/or improving tools for assisting in smell detection and refactoring, or designing and/or revising (company’s)

strategies for refactoring or managing technical debt.

can be located on levels 3 to 6 (see Table 2). Lev-

els 1 and 2 are more knowledge-oriented. For further

details, also see (Haendler and Neumann, 2019).

Smell Types and Learning Objects. According to

the different quality aspects (w.r.t artifact types and/or

abstraction levels), several Smell Categories and

types of Technical Debt Items (see

 in Fig. 2)

can be distinguished (Alves et al., 2016), such as the

following:

• code smells (Fowler et al., 1999)

• software design or architecture smells (Surya-

narayana et al., 2014)

• test smells (Bavota et al., 2012)

• requirements smells (Femmer et al., 2017)

• model smells (Misbhauddin and Alshayeb, 2015)

Each Smell Type (or Smell Category) can be seen

as a learning object, i.e. as a content item or chunk

for a learning unit. For instance, such as a unit for

MODULARIZATION smells as sub-group of software

design smells, see (Suryanarayana et al., 2014).

Analysis and Assessment. According to the types

of smells (see above) and their symptoms, different

quality Metrics can be applied (Kan, 2002) to iden-

tify them, also in different artifact types. For this pur-

pose, two types of Quality Analyzers (see

 in

Fig. 2) are exemplary listed that pursue the (mostly

static) analysis of the internal quality of system arti-

facts:

• Smell detection and refactoring recommendation

tools that support identifying smell and refactor-

ing candidates via symptoms based on certain

metrics; e.g., JDeodorant (Tsantalis et al., 2008)

or DECOR (Moha et al., 2010).

• Technical-debt analyzers applying different met-

rics for measuring and quantifying a system’s

debt in terms of person hours to ﬁx (repay) the

debt; e.g., SonarQube (Campbell and Papapetrou,

2013) JArchitect (CoderGears, 2018) or NDepend

(ZEN PROGRAM, 2018).

Besides the analysis of the internal code quality, test

frameworks (such as XUnit or scenario tests) are com-

monly in use in terms of run-time regression tests that

ensure that no errors have been introduced while mod-

ifying the source code. As described above (Section

4.1), tool-supported analysis can be applied for as-

sessing and evaluating the user’s actions and moves.

The choice of tool and what information provided to

the user (in terms of decision support and feedback)

impacts the addressed refactoring competences (see

below).

Decision Support and Learning Objectives. De-

pending on the analysis information provided by anal-

ysis tools (see above) presented to the user in terms of

decision support and feedback, different competences

are addressed (see Table 3).

Via the integration of regression-testing frame-

works, the functional correctness (w.r.t. the speciﬁed

tests) can be assessed. This way, the low-level task

(1) in Table 3 of performing code modiﬁcations that

do not change the external behavior of the system (i.e.

refactoring) can be automatically assessed, which lays

the basis for further tasks and assessments. In order

to address the competence of (2) identifying refactor-

ing candidates (e.g., code smells), the technical debt

score can be provided to the user, which indicates the

existence but not the location of the debt item in the

system’s artifact. For (3) planning and performing

refactoring steps, ﬁnally a combination of regression

CSEDU 2019 - 11th International Conference on Computer Supported Education

Table 3: Decision support provided by analysis tools (hor-

izontal) with addressed refactoring tasks and competence

levels (vertical).

Task regression

testing

TD mea-

sured

smells

identiﬁed

ref. op-

tions

(1) behavior pre-

serving code mod-

iﬁcation

u – – –

(2) identiﬁcation of

ref. candidates

– u – –

(3) planning and

performing ref.

steps

u u u –

(4) strategy selec-

tion

u u u u

testing, measured technical debt and also the location

of concrete smells (as provided by smell detectors, see

above) can be presented to the user. For addressing

the competence of (4) strategy selection, in addition

to the identiﬁed smells also the refactoring options

(provided by refactoring recommendation tools) can

be presented to the user. In this case, the challenge

is in prioritizing the given smells and evaluating the

already available options for refactoring. For corre-

sponding competence levels, also see Table 2.

Aesthetics. While the Goal of a refactoring game

can be generally seen in increasing the system quality

by removing smells or reducing technical debt score

(or parts of that, e.g., identifying smells), the Mission

as the narrative purpose of the game (as motivation

for the user) can differ from this. Via emotional re-

sponses from a game (evoked by the applied under-

lying game dynamics), a user is motivated to accom-

plish the set game Mission (Hunicke et al., 2004).

The MDA framework suggests 8 kinds of Aesthetic

Aspects for game designs (see Table 4).

Table 4: Exemplary aesthetic aspects for game designs (Hu-

nicke et al., 2004).

Fun aspect Description

(1) Sensation Game as sense-pleasure

(2) Fantasy Game as make-believe

(3) Narrative Game as drama

(4) Challenge Game as obstacle course

(5) Fellowship Game as social framework

(6) Discovery Game as uncharted territory

(7) Expression Game as self-discovery

(8) Submission Game as pastime

For refactoring games, the following exemplary con-

ditions can evoke aesthetic aspects. As a Chal-

lenge aspect can be seen the identiﬁcation of smells

and/or performing of refactorings, especially when

performed under time pressure (Time Constraint;

see

 in Fig. 2). In case the player acts in a cer-

tain role in a deﬁned scenario (such as the role of

a software developer confronted with quality issues),

the Narrative aspect can be seen addressed. In gen-

eral, playing a refactoring game in team or compet-

ing against each other for (collectively) improving the

code quality may be regarded as Fellowship aspect. In

addition, also the Discovery can be addressed, e.g., by

letting the player explore system artifacts for identify-

ing refactoring candidates.

Game Types. With focus on games for the train-

ing of technical and engineering-related competences,

we can distinguish three Game Types, i.e., game-

based learning, gamiﬁcation, and serious game. In

particular, the term game-based learning reﬂects the

use of games for learning purposes (Prensky, 2003),

which also includes simple game designs with the

goal to mediate knowledge and understanding (i.e.,

lower levels of competences in Bloom’s taxonomy).

Gamiﬁcation can be deﬁned as using game-design el-

ements in non-gaming contexts (Huotari and Hamari,

2012). For software engineering (and refactoring in

particular), gamiﬁcation can be regarded as extend-

ing development and engineering activities (which

are based on certain SE tools) by gaming elements,

also see (Garc

ıa et al., 2017). Moreover, serious

gaming means playing games with a certain purpose,

e.g., educational or training games (Landers, 2014).

In addition (and in contrast to game-based learn-

ing), serious games are regarded to provide real-world

conditions (e.g., via video-based simulations (Con-

nolly et al., 2012)) and to target higher-level compe-

tences. Furthermore, serious games and gamiﬁcation

are often grouped together, but they differ regarding

the scope/depth of game structure. Basically, seri-

ous games aim to provide typical game mechanics

(e.g., consisting of game moves and goal/mission),

while gamiﬁcation approaches focus on the (some-

times modest) application of gaming elements such

as certain (social) feedback mechanisms (e.g., points,

badges, leaderboards).

5 ANALYZING GAME

APPROACHES

Here we illustrate by example how the ontology can

be used for analyzing existing game designs. In ad-

dition, in Section 6, we also reﬂect on applying the

approach for reasoning about novel game designs.

In research literature, only a few approaches for

refactoring games can be identiﬁed. Based on current

Ontology-based Analysis of Game Designs for Software Refactoring

Table 5: Comparison of exemplary refactoring-game approaches according to ontology-based design options.

Design Aspect (A) (Raab, 2012) (B) (Elezi et al., 2016) (C) (Khandelwal et al., 2017)

Tasks and Ac-

tions

Identify refactoring opportunities and perform cor-

responding refactorings in small code examples in

the framework of a learning path (with single- and

multiple-choice questions)

Identify code smells and select appropriate refac-

torings in real-world code base and trigger the ex-

ecution of Eclipse refactoring commands

Review source code produced by peers for identi-

fying code smells and bugs

Mission Master the set learning path by accomplishing the

learning units

Collectively improve quality of real-world code;

compete against fellow developers while collecting

points for performing code refactoring

Experience the use of gamiﬁcation elements while

reviewing the code produced by peers for identify-

ing code smells and bugs

Aesthetic Aspect Challenge, discovery, sensation Challenge, fellowship, narrative Challenge, (discovery)

Target Compe-

tences

Identify smells and refactoring options as well as

perform refactorings (small examples)

Assess and prioritize refactoring candidates in

(real-world) code

Identify code smells (and bugs) while reviewing the

code (larger examples)

Prerequisite

Competences

Understanding the (basic) rules/symptoms for (1)

identifying selected smell types and (2) performing

refactoring steps

Using Eclipse refactoring tool Understanding the rules/symptoms for identifying

selected smell types (and bugs)

Smell types Basic stylistic code and design smells, based on

(Fowler et al., 1999)

Code smells according to Eclipse’s code smell de-

tector

Stylistic code smells (clean code)

Modiﬁed Artifacts Small code examples Real-world code base Code base produced by peers (in the framework

of a programming exercise)

Views / Feedback Editor/code, tangible cards/slides (with general

refactoring information), interactive screen for vi-

sualizing refactoring options (in terms of a graph,

see below)

Editor/code, leaderboards, activity feed, progress

bar

Editor/code, leaderboards, activity stream

Decision support Tangible cards with general information on se-

lected smell types as well as dependency graph

(between smell types and related refactoring tech-

niques)

List of identiﬁed and source-located refactoring

candidates as well as refactoring recommendation

and automation

General information on symptoms of a selected

set of most common code smells

Assessment /

Evaluation

Automated assessment of multiple-choice ques-

tions enhanced by human evaluation of code-

modiﬁcation tasks

Tracking of command execution and automated

assessment in terms of a score via pre-deﬁned dif-

ﬁculty levels

Peer reviews of code (i.e. actual task, no assess-

ment in narrow sense)

Rewards Several kinds of animations and sounds Score points and levels Likes, badges

Tools or games

integrated

– Eclipse refactoring tool Code-review tool

User interaction Informal, in terms of discussions between users Competitive and indirect via shared leaderboards Competitive and indirect via shared leaderboards

Game levels /

learning units

Path consisting of sequence of learning units Documented progress (e.g., levels, bar charts) –

Type of game Game-based learning Gamiﬁcation Gamiﬁcation

systematic literature reviews (SLRs) on serious games

in programming (Miljanovic and Bradbury, 2018),

gamiﬁcation in software engineering (education) (Pe-

dreira et al., 2015; Alhammad and Moreno, 2018) and

further review, only the following four approaches for

applying games in the ﬁeld of software refactoring

have been identiﬁed (i.e., with regard to gamiﬁcation,

game-based learning or serious gaming).

(A) (Raab, 2012)

(B) (Elezi et al., 2016)

(D) (Haendler and Neumann, 2019)

Since approach (D) represents a design for serious

games proposed by the authors of this paper, we fo-

cus on the other three design approaches for analysis.

In Table 5, these identiﬁed approaches are evaluated

according to ontology-based design options and fur-

ther concept values of the ontology as described in

Section 4.2 . In particular, the values for the follow-

ing design aspects have been attributed to approaches

(A–C): addressed refactoring tasks and actions, the

game mission, the addressed aesthetic aspects, the

addressed (prerequisite and target) competences, the

kinds of refactoring candidates (smell types), the ar-

tifacts modiﬁed by the users, the provided views and

feedback as well as decision-support mechanisms, the

techniques of assessment and evaluation, the kinds of

rewards, whether pre-existing tools and games have

been included, the interactions between users, the

kind of game progress and the type of game (e.g.,

game-based learning or gamiﬁcation).

As described in Table 5, all three analyzed game

designs address i.a. the task (and target competence)

of identifying candidates for refactoring smells (i.e.,

on code level). However, in addition to this, they

differ in terms of further tasks and (levels of) com-

petences. These differences are correlated with the

choice of game-design options, such as the game mis-

sion, the size of artifacts to be analyzed and modiﬁed,

as well as the kinds of decision and tool support.

In particular, approach (A) (Raab, 2012) proposes

a game-based learning approach for learning to iden-

tify smells and refactoring options as well as to per-

form refactorings in small code examples (also see

Table 5). The exercises (e.g., multiple-choice ques-

tions) are framed by a learning path with several

learning units. As decision support, tangible cards

with general information on selected smell types are

provided as well as an interactive screen with a visu-

alization of smell types and related refactoring tech-

niques. the result of multiple-choice questions are as-

sessed automatically, the code modiﬁcations by the

instructor. For this game, the theoretical knowledge

on rules/symptoms for identifying smells and per-

forming corresponding refactorings is required. The

target audience can be regarded as primarily novices,

e.g., in terms of (university) students aiming to gain

ﬁrst practical refactoring competences.

CSEDU 2019 - 11th International Conference on Computer Supported Education

Approach (B) (Elezi et al., 2016) in turn is based

on real-world code bases and integrates a refactoring

tool (in Eclipse) for identifying code smells and se-

lecting appropriate refactorings. The approach can be

classiﬁed as gamiﬁcation, since it adds gaming ele-

ments (such as leaderboards, activity feed) to a real-

world setting with the purpose of fostering motiva-

tion. For each successful refactoring, a user scores

points. The mission is to collectively improve code

quality by competing against fellow developers. The

integrated tool provides high-level decision support

by suggesting refactoring candidates and then auto-

matically performing them. Thus, this game’s tech-

nical challenge is to prioritize the candidates. The

user’s performance is assessed by tracking the com-

mand execution within the Eclipse refactoring tool

and weighting them in scores according to their dif-

ﬁculty level. An important prerequisite competence

lays in using the applied refactoring tool. Software

developers can generally be regarded as the target

group of this approach.

Finally, approach (C) (Khandelwal et al., 2017)

proposes the gamiﬁcation in performing code reviews

for answering the question whether a playful environ-

ment can foster users’ motivation. For this purpose,

code-review tools are extended by several gaming el-

ements (such as likes and badges). The users then re-

view code developed by peers for identifying smells

and bugs. For decision support only general informa-

tion on symptoms of a selected set of most common

code smells are presented to the user. Target audience

of this approach are primarily also software develop-

ers.

The analysis shows that existing approaches for

games in software refactoring (identiﬁed in recent

SLRs, see above) cover only a few of the possible as-

pects (i.e., design options) presented in the proposed

domain-ontology. In particular, games (B) (Elezi

et al., 2016) and (C) (Khandelwal et al., 2017) rep-

resent approaches for gamifying software engineer-

ing tools (i.e., a refactoring tool and a code-review

tool) by adding single gaming elements. Their fo-

cus is less on mediating competences than on fos-

tering users’ motivation to perform the activities. In

contrast, approach (A) (Raab, 2012) proposes game-

based learning for small code examples and simple

smell types and thus only addresses lower-level com-

petences according to Bloom’s taxonomy (see Table

2). All three approaches focus on smells on the code

level (i.a., stylistic code smells), whereas more com-

plicated smells can be found, for instance, on the level

of software design and architecture (Suryanarayana

et al., 2014) or in other kinds of artifacts.

6 DISCUSSION

In this paper, we have developed a domain ontology

for representing the concepts relevant for games in the

ﬁeld of software refactoring. We have illustrated how

the resulting ontology and the corresponding design

aspects and options can be used for analyzing exist-

ing games. The analysis has shown by example that

the covered concepts are appropriate to analyze and

classify game designs for software refactoring. In ad-

dition, the analysis indicates that there is further po-

tential for game approaches, especially in the sense of

serious games, that aim to acquire practical compe-

tences in refactoring (Haendler and Neumann, 2019).

Game

Designer

Instructor

Learner

Player

Mechanics

Target

Competences

Actual

Competences

Dynamics Aesthetics

creates game

plays game

mediates competences

acquires competences

Lead

Engineer

Learning

Environment

Engineer

Actual

Artifact Quality

improves artifact quality by refactoring

Intended

Artifact Quality

(optionally) de

nes mission/goal and tasks

Analysis

Tools

Figure 3: Layers relevant for development of game design.

Ontology-Supported Game Design. In addition to

the game analysis, we believe that the ontology can

support in designing novel game designs. As starting

point for designing games, we can consider the fol-

lowing three scenarios (also see Fig. 3):

 From target competences to game. How to de-

sign a game that addresses certain competences?

 From existing game to target competences.

How to use an existing gaming environment to ad-

dress certain competences?

 From existing SE tools to game that addresses

target competences. How to gamify a develop-

ment environment in order to address certain com-

petences?

The developed ontology provides support for reason-

ing about game design from all three viewpoints. Fig.

3 depicts an overview of the three layers relevant for

game designs in software refactoring covered by the

ontology. In case

 (see Fig. 3), the instructor is pri-

marily also in the role of the game designer (i.e., the

game infrastructure is devoted to learning purposes).

Starting from prerequisite and target competences,

she can consult the ontology for possible design op-

tions in game-design mechanics, e.g., what kinds of

actions/moves to be performed and which tools to in-

Ontology-based Analysis of Game Designs for Software Refactoring

tegrate, and game dynamics, e.g., what kinds of infor-

mation presented to the user, and also regarding user

interaction. In case

, the instructor aims to mod-

ify and adapt an existing gaming environment in or-

der to address certain (target) competences. Depend-

ing to existing game mechanics (and integrated tools),

she can explore the options for decision support and

feedback (provided by the tools) and consider user-

interaction and other (motivational) feedback mech-

anisms. Case

 describes the typical gamiﬁcation

approach, i.e., based on existing SE tools and activi-

ties, it is aimed to add gaming elements. Starting from

the technical sub-domains in

 and

 in Fig. 2, she

can (based on applied SE tools) reﬂect on design op-

tions for game mechanics, dynamics and aesthetics

(see

) in order to address certain (target) compe-

tences (see

 and

).

Further Potential. The development of the domain

ontology was driven by the motivation to better un-

derstand the concepts relevant for designing (train-

ing) games in the ﬁeld of software refactoring. Thus,

its scope is focus on corresponding concepts. For a

broader application purpose, e.g., for designing and

analyzing games in computer programming and soft-

ware engineering, certain domain-speciﬁc concepts

need to be extended. However, we believe that the

resulting ontology can be used and adapted for other

technical domains. For instance, in case of design-

ing games for training requirements-engineering tech-

niques, the concepts in sub-domains

 to

 in Fig.

2 can be reused. For this purpose, concepts in

 and

 need to be replaced by corresponding concepts

(e.g., activities, artifacts and tools) for requirements

engineering.

7 CONCLUSION

In this paper, we presented an approach for devel-

oping a unifying ontology for representing concepts

and design options relevant for (educational) games in

software refactoring. For creating the ontology, con-

cepts from ﬁve related existing domain ontologies and

taxonomies from the ﬁelds of game design, software

refactoring and competence management have been

reused, combined and extended.

As a result of this process, a domain ontol-

ogy in terms of a meta-model documented as UML

class diagram is presented. The ontology provides

an overview of concepts (and dependencies between

concepts) relevant for games in software refactoring.

In addition to the model, possible design options (i.e.,

ontology instances) are described in detail. More-

over, it has been demonstrated by example that the

ontology can be used to analyze existing gaming ap-

proaches and provides potential for supporting game

designers and instructors in the process of developing

novel refactoring-game designs.

Based on the analysis of existing approaches, we

see potential for games addressing further aspects in

order to promote practical competences and motiva-

tion in software refactoring. For future work, we plan

to extend our serious-gaming approach (Haendler and

Neumann, 2019) to a generic gaming framework for

refactoring that provides variable design options to

the instructor, e.g., in order to address different com-

petence levels and allow the ﬂexible integration of

analysis tools.

REFERENCES

Alhammad, M. M. and Moreno, A. M. (2018). Gamiﬁca-

tion in software engineering education: A systematic

mapping. J. Systems and Software, 141:131–150.

Alves, N. S., Mendes, T. S., de Mendonc¸a, M. G., Sp

ınola,

R. O., Shull, F., and Seaman, C. (2016). Identiﬁca-

tion and management of technical debt: A systematic

mapping study. Information and Software Technology,

70:100–121.

Avgeriou, P., Kruchten, P., Ozkaya, I., and Seaman, C.

(2016). Managing technical debt in software engineer-

ing (dagstuhl seminar 16162). In Dagstuhl Reports,

volume 6. Schloss Dagstuhl-Leibniz-Zentrum fuer In-

formatik.

Bavota, G., Qusef, A., Oliveto, R., De Lucia, A., and Bink-

ley, D. (2012). An empirical analysis of the distribu-

tion of unit test smells and their impact on software

maintenance. In Proc. of ICSM 2012, pages 56–65.

IEEE.

Bloom, B. S. et al. (1956). Taxonomy of educational objec-

tives. vol. 1: Cognitive domain. New York: McKay,

pages 20–24.

Britto, R. and Usman, M. (2015). Bloom’s taxonomy in

software engineering education: A systematic map-

ping study. In Frontiers in Education Conference

(FIE), 2015 IEEE, pages 1–8. IEEE.

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

action. Manning Publications Co.

CoderGears (2018). JArchitect. http://www.jarchitect.com/

[March 25, 2019].

Connolly, T. M., Boyle, E. A., MacArthur, E., Hainey, T.,

and Boyle, J. M. (2012). A systematic literature re-

view of empirical evidence on computer games and

serious games. Computers & Education, 59(2):661–

686.

Elezi, L., Sali, S., Demeyer, S., Murgia, A., and P

erez, J.

(2016). A game of refactoring: Studying the impact

of gamiﬁcation in software refactoring. In Proc. of the

Scientiﬁc Workshops of XP2016, page 23. ACM.

CSEDU 2019 - 11th International Conference on Computer Supported Education

Femmer, H., Fern

andez, D. M., Wagner, S., and Eder, S.

(2017). Rapid quality assurance with requirements

smells. J. Systems and Software, 123:190–213.

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.

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

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

ing code. Addison-Wesley Professional.

Garc

ıa, F., Pedreira, O., Piattini, M., Cerdeira-Pena, A.,

and Penabad, M. (2017). A framework for gamiﬁca-

tion in software engineering. J. Systems and Software,

132:21–40.

Guizzardi, G., Herre, H., and Wagner, G. (2002). On the

general ontological foundations of conceptual model-

ing. In International Conference on Conceptual Mod-

eling, pages 65–78. Springer.

Haendler, T. and Frysak, J. (2018). Deconstructing

the refactoring process from a problem-solving and

decision-making perspective. In Proc. of the 13th In-

ternational Conference on Software Technologies (IC-

SOFT), pages 363–372. SciTePress.

Haendler, T. and Neumann, G. (2019). Serious refactor-

ing games. In Proc. of the 52nd Hawaii International

Conference on System Sciences (HICSS), pages 7691–

7700.

Haendler, T., Neumann, G., and Smirnov, F. (2019). An

interactive tutoring system for training software refac-

toring. In Proc. of the 11th International Conference

on Computer Supported Education (CSEDU).

Hamari, J., Koivisto, J., and Sarsa, H. (2014). Does gami-

ﬁcation work?–a literature review of empirical studies

on gamiﬁcation. In Proc. of 47th Hawaii International

Conference on System Sciences (HICSS), pages 3025–

3034. IEEE.

Hunicke, R., LeBlanc, M., and Zubek, R. (2004). MDA: A

formal approach to game design and game research. In

Proc. of the AAAI Workshop on Challenges in Game

AI, volume 4, pages 1–5. AAAI Press San Jose, CA.

Huotari, K. and Hamari, J. (2012). Deﬁning gamiﬁcation: a

service marketing perspective. In Proc. of the 16th in-

ternational academic MindTrek conference, pages 17–

22. ACM.

Kan, S. H. (2002). Metrics and models in software qual-

ity engineering. Addison-Wesley Longman Publish-

ing Co., Inc.

Khandelwal, S., Sripada, S. K., and Reddy, Y. R. (2017).

Impact of gamiﬁcation on code review process: An

experimental study. In Proc. of the 10th Innovations

in Software Engineering Conference, pages 122–126.

ACM.

Kitchenham, B. A., Travassos, G. H., Von Mayrhauser, A.,

Niessink, F., Schneidewind, N. F., Singer, J., Takada,

S., Vehvilainen, R., and Yang, H. (1999). Towards an

ontology of software maintenance. J. Software Main-

tenance: Research and Practice, 11(6):365–389.

Krathwohl, D. R. (2002). A revision of Bloom’s taxonomy:

An overview. Theory into practice, 41(4):212–218.

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

debt: From metaphor to theory and practice. IEEE

software, 29(6):18–21.

Landers, R. N. (2014). Developing a theory of gamiﬁed

learning: Linking serious games and gamiﬁcation of

learning. Simulation & Gaming, 45(6):752–768.

Masapanta-Carri

on, S. and Vel

azquez-Iturbide, J.

(2018). A systematic review of the use of Bloom’s

taxonomy in computer science education. In Proc. of

the 49th ACM Technical Symposium on Computer Sci-

ence Education, pages 441–446. ACM.

Miljanovic, M. A. and Bradbury, J. S. (2018). A review

of serious games for programming. In Joint Interna-

tional Conference on Serious Games, pages 204–216.

Springer.

Misbhauddin, M. and Alshayeb, M. (2015). UML model

refactoring: a systematic literature review. Empirical

Software Engineering, 20(1):206–251.

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 Trans-

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

Noy, N. F., McGuinness, D. L., et al. (2001). Ontology

development 101: A guide to creating your ﬁrst ontol-

ogy.

Object Management Group (2015). Uniﬁed Mod-

eling Language (UML), Superstructure, Version

2.5.0. http://www.omg.org/spec/UML/2.5 [March 25,

2019].

Opdyke, W. F. (1992). Refactoring object-oriented frame-

works. University of Illinois at Urbana-Champaign

Champaign, IL, USA.

Paquette, G. (2007). An ontology and a software framework

for competency modeling and management. Educa-

tional Technology & Society, 10(3):1–21.

Paulheim, H. (2017). Knowledge graph reﬁnement: A sur-

vey of approaches and evaluation methods. Semantic

web, 8(3):489–508.

Pedreira, O., Garc

ıa, F., Brisaboa, N., and Piattini, M.

(2015). Gamiﬁcation in software engineering–a sys-

tematic mapping. Information and Software Technol-

ogy, 57:157–168.

Prensky, M. (2003). Digital game-based learning. Comput-

ers in Entertainment (CIE), 1(1):21–21.

Raab, F. (2012). Codesmellexplorer: Tangible exploration

of code smells and refactorings. In Visual Lan-

guages and Human-Centric Computing (VL/HCC),

2012 IEEE Symposium on, pages 261–262. IEEE.

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

(2014). Refactoring for software design smells: Man-

aging 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., Chaikalis, T., and Chatzigeorgiou, A. (2008).

JDeodorant: Identiﬁcation and removal of type-

checking bad smells. In Proc. of 12th European Con-

ference on Software Maintenance and Reengineering

(CSMR 2008)., pages 329–331. IEEE.

ZEN PROGRAM (2018). NDepend.

http://www.ndepend.com/ [March 25, 2019].

Ontology-based Analysis of Game Designs for Software Refactoring