Can Abstraction Be Taught?

Refactoring-based Abstraction Learning

Naoyasu Ubayashi, Yasutaka Kamei and Ryosuke Sato

Kyushu University, Fukuoka, Japan

Keywords:

Abstraction, Reﬁnement, Abstraction-aware Refactoring.

Abstract:

Can the notion of abstraction be taught to students? It is a very difﬁcult question. Abstraction plays an impor-

tant role in software development. This paper shows that refactoring is effective for students to learn the notion

of abstraction. We focus on design abstraction, because it is one of the crucial parts in teaching the essence

of software engineering. To explore for a well-balanced separation of concerns between design and code, it

is not avoidable to go back and forth between them. To help a student ﬁnd an appropriate abstraction level,

we introduce abstraction-aware refactoring patterns consisting of MoveM2C (Move concerns from Model to

Code) and CopyC2M (Copy concerns from Code to Model). The patterns enable a student to reﬁne abstraction

while preserving not only external functionality but also traceability between design and code.

1 INTRODUCTION

Can the notion of abstraction be effectively taught

to students? It is a very difﬁcult question. Ab-

straction plays an important role in software devel-

opment. J. Kramer not only claims that abstraction

is crucial for computing professionals but also raises

questions (Kramer, 2007): Why is it that some soft-

ware engineers and computer scientists are able to

produce clear, elegant designs and programs, while

others cannot? Is it possible to improve these skills

through education and training? His hypothesis is

that critical to these questions is the notion of abstrac-

tion. Many researchers and developers agree that ab-

straction is one of the most important skills in soft-

ware engineering. However, there are different as-

pects of abstraction: abstraction in design speciﬁca-

tions, abstraction in program modules, abstraction in

software architectures, and so on. In this paper, we

focus on abstraction between design and implementa-

tion, because it is one of the crucial parts in teaching

the essence of software engineering to university stu-

dents. In many universities, programming is taught

ﬁrst and after that software design is taught. Most

students feel that there is a big gap between software

design and programming in terms of abstraction.

This paper shows that refactoring crosscutting

over design and code is effective for ordinary students

to learn the notion of abstraction. In (Batini and Vis-

cusi, 2016), the etymology of abstraction is shown as

follows: (14c.) from Latin abstractionem (nomina-

tive abstractio), noun of action from past participle

stem of abstrahere “drag away, pull away, divert”.

From this etymology, abstraction can be deﬁned as

removal of details. There are two different abstrac-

tions: abstraction by forgetting (details) and abstrac-

tion by hiding. Class hierarchy is an example of the

former type. On the other hand, the latter type is cru-

cial in terms of abstraction between design and code,

because design is a speciﬁcation of software architec-

ture (Shaw and Garlan, 1994) hiding detail implemen-

tation.

In this paper, we introduce a set of patterns for

abstraction-aware refactoring. The patterns consist

of MoveM2C (Move concerns from Model to Code)

and CopyC2M (Copy concerns from Code to Model).

In our educational experience, students often fail to

make a model at the ﬁrst time, because they cannot

understand to what extent the model should be de-

tailed. Some students make a very detailed model

equal to the program code. Such a model is hard to

maintain, because it has to be modiﬁed whenever the

code is revised. Some students make a too abstract

model containing only few model elements and can-

not understand how to relate the model to the code.

They have the knowledge of UML notations but do

not understand in depth what is abstraction. On the

other hand, it is relatively easy for them to write a

program, although abstraction skills in programming

might be insufﬁcient. Our teaching objective is to

Ubayashi, N., Kamei, Y. and Sato, R.

Can Abstraction Be Taught? Refactoring-based Abstraction Learning.

DOI: 10.5220/0006604804290437

In Proceedings of the 6th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2018), pages 429-437

ISBN: 978-989-758-283-7

429

help students understand how to remove details at the

beginning of learning modeling. Traditional refactor-

ing (Fowler, 1999) improvesthe code structures while

preserving the external functionality. Our refactor-

ing patterns reﬁne abstraction while preserving not

only external functionality but also traceability be-

tween design and code. Traceability is important for

students to understand how a model is related to the

code in software development. Although it is prefer-

able to ﬁrmly separate design from its implementa-

tion (or hide non-essential implementation details),

this separation is not easy for many students because

an abstraction level—How much should a design be

more abstractthan code?—tendsto change during the

progress of software development. In general, an im-

portant decision on software architecture is made at

the design phase and a decision on the detailed pro-

gram structure concerning API usages, variables, and

methods is made at the coding phase. However, this

distinction is relative and vague in many cases. R. N.

Taylor et al. pointed out the need for adequate sup-

port for ﬂuidly moving between design and coding

tasks (Taylor and Hoek, 2007). Because of ﬂuid mov-

ing, abstraction level may ﬂuidly change as a result

of reconsidering the balance between design and its

implementation—which concern should be described

in design and which concern should be written in

code. Our refactoring patterns supports ﬂuid abstrac-

tion, a design approach in which appropriate abstrac-

tion can be captured by the convergence of ﬂuid mov-

ing and removing details. Why do we use the word

ﬂuid abstraction? The reason is that abstraction in de-

sign and coding phases should not be absolutely given

by a teacher but be ﬂexible for a student to seek the

best combination of design and code.

We evaluated the effectiveness of the proposed

refactoring patterns by applying them to a system

developed in our university’s PBL (Project-Based

Learning) class. This experiment gave us the interest-

ing knowledge about teaching software development

in terms of abstraction. We addressed three research

questions: RQ1) How much value does an abstrac-

tion level become in an educational project? ; RQ2)

What becomes the trigger of applying the refactoring

patterns? ; and RQ3) Does an abstraction level ﬁnally

convergeto a certain value by applying the refactoring

patterns? For RQ1, the abstraction level l (0 ≤ l ≤ 1)

was about around 0.5 in the educational system devel-

opment. For RQ2, we could extract two bad smells

triggering abstraction-aware refactoring: “abnormal

abstraction level” and “inconsistency between design

and code.” For RQ3, all design models converged to

the similar abstraction level. We consider that the ex-

istence of a converged abstraction level is important

for a student to capture an abstraction skill, because

he or she can understand that there is an abstraction

structure in a real system.

This paper is structured as follows. The techni-

cal background needed to understand our approach

is brieﬂy explained in Section 2. Abstraction-aware

refactoring patterns are introduced in Section 3. In

Section 4, we show iArch, a support tool for apply-

ing the refactoring patterns. In Section 5, we show

the evaluation results in our university’s PBL class.

In Section 6, we show related work. Concluding re-

marks are provided in Section 7.

2 BACKGROUND

In this section, we introduce the technical back-

ground of the abstraction-aware refactoring patterns.

Our approach is based on an interface mechanism

that represents a contract between design and code.

This interface is called Archface (Architectural Inter-

face) (Ubayashi et al., 2014). A student has to deﬁne

this interface that enforces the student to decide which

concern should be included in both a design model

and code. The student has to removethe non-essential

details from the design model by not specifying them

in the interface.

2.1 Archface

Archface exposes architectural points shared between

design and code. These points termed archpoints have

to be modeled as design points in a UML model and

have to be implemented as program points in its code.

Archface is a contract that should be guaranteed be-

tween design and code in terms of abstraction. An

abstraction level is determined by selecting archpoints

that should be shared between design and code. There

are two kinds of type checking: type check between

Archface and a UML model; and type check between

Archface and code. If both type checks are correct,

a design model is traceable to the code in terms of a

deﬁned abstraction level.

Table 1 shows design points, program points, and

archpoints. It is easy for a student to understand

which archpoint corresponds to a model element (de-

sign point) in a design model or a program snip-

pet (program point). We limited archpoints to basic

points that can be easily understood by students, al-

though more complex archpoints can be introduced

(e.g., data ﬂow archpoints). There are several mer-

its in using the notion of points. One of the essential

merits is that points are countable and an abstraction

level can be easily calculated. There are two types of

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

430

Table 1: Design Points, Program Points, and Archpoints.

Design point Program point Archpoint

(UML2 metamodel) (Java)

Class

class a class

Operation

method a method

Property

ﬁeld a ﬁeld

Message MessageEnd

method call a mcall

(

sendEvent

)

Message MessageEnd

method exec a mexec

(

receiveEvent

)

archpoints: structural archpoints based on class struc-

tures and behavioral archpoints based on LTS (La-

belled Transition Systems). Both structural and be-

havioral aspects are essential in learning modeling.

Archface, which supports component-and-

connector architecture (Allen and Garlan, 1994),

consists of two kinds of interface: component and

connector. The former exposes archpoints and the

latter deﬁnes how to coordinate them. An Archface

deﬁnition of the Observer pattern is shown in List 1.

[List 1] -- Java & FSP Syntax

01: interface component cSubject {

02: public void addObserver(Observer);

03: public void removeObserver(Observer);

04: public String getState();

05: public void setState(String);

06: }

07:

08: interface component cObserver {

09: public void update();

10: }

11:

12: interface connector cObserverPattern

13: (cSubject, cObserver){

14: cSubject = (cSubject.setState->cObserver.update

15: ->cSubject.getState->cSubject);

16: cObserver = (cObserver.update->cSubject.getState

17: ->cObserver);

18: }

The structural aspect is described as a Java-like

interface and the behavioral aspect is speciﬁed using

process algebra. That is, message interactions are de-

scribed based on FSP (Finite State Processes) (Magee

and Kramer, 2006) whose speciﬁcations generate ﬁ-

nite LTS. The notation → indicates a control ﬂow

represented by a method call. An interaction be-

tween a subject and observers is deﬁned in line 14-

17. A message is sent from a subject to an observer by

cObserver.update

in line 14 and 16. The

cSubject

is speciﬁed as a process that repeatedly receives

setState

, sends

update

to the

cObserver

, and re-

ceives

getState

. In the same way, the

cObserver

speciﬁed as a process that repeatedly receives

update

and sends

getState

to the

cSubject

2.2 Abstraction-aware Compiler

The conformance to Archface can be checked by a

type system taking into account not only programs

but also design models. Type checking is performed

by verifying whether or not a design point (program

point) corresponding to an archpoint exists in a design

model (program) while satisfying constraints among

design points (program points) (e.g., the order of mes-

sage sequences). Although traditional types are struc-

tural, Archface is based on archpoints including be-

havior. The reason is because a design model imposes

structural or behavioral architectural constraints on a

program. Our type checker veriﬁes the simulation re-

lation between a design model and its code via FSP

descriptions in Archface. Fixing inter-model incon-

sistency is an important problem (Egyed et al., 2008)

when students understand how a diagram is related to

other diagrams and which role each diagram has. Our

compiler can verify inconsistency not only between a

model and code but also between models.

2.3 Abstraction Level

An abstraction level—How much should a design

model be more abstract than its code?—is determined

by selecting archpoints that should be shared between

design and code. The abstraction ratio is a metric

for measuring an abstraction level. The value of this

metric is 1−#ArchPoint/#ProgramPoint. #ArchPoint

and #ProgramPoint are the number of archpoints and

program points, respectively. We provided a simple

metric for a student to understand abstraction intu-

itively and quantitatively. #DesignPoint, the number

of design points, can be larger than #ArchPoint when

there are design concerns that are not reﬂected into

the code. On the other hand, #ArchPoint indicates

the number of design points that should be reﬂected

to the code. The value of this metric ranges from 0

to 1. A large value close to 1 indicates that the ab-

straction level is high. A small value close to 0 in-

dicates that the abstraction level is low. The number

of archpoints and program points is automatically cal-

culated from the Archface deﬁnitions by our support

tool iArch shown in Section 4. In case of Ratio = 0,

all archpoints are mapped to the corresponding pro-

gram points. This case indicates that a model is equal

to the code. In case of Ratio = 1, there are no design

descriptions corresponding to a program. There are

no archpoints. A software artifact that does not con-

tain design descriptions is an example of this case.

3 REFACTORING PATTERNS

In this section, we introduce the abstraction-aware

refactoring patterns that help a student explore an ap-

propriate abstraction level ranging between 0 and 1.

The refactoring proposed by us reﬁnes an abstraction

level while preserving not only external functionality

Can Abstraction Be Taught? Refactoring-based Abstraction Learning

431

Table 2: Abstraction-aware Refactoring Patterns.

Category Pattern Abbreviation Explanation Abstraction

Remove Class

RmCs Remove a non-important class. ր

Remove Sub Class

RmSubCs Remove a non-important sub class. ր

Structural

Remove Library Class

RmLibCs Remove a non-important API class. ր

MoveM2C

Remove Method

RmMs Remove a non-important method. ր

Remove Field

RmFd Remove a non-important ﬁeld. ր

Behavioral

Remove Message

RmMsg Remove non-important message ր

Remove API Call

RmAPI Remove a non-important API call. ր

Remove Object

RmObj Remove a non-important object. ր

Add Class

AddCs Add an important class existing in

the code to its design model.

Add Sub Class

AddSubCs Add an important sub class existing

in the code to its design model.

Structural

Add Library Class

AddLibCs Add an important API class existing

in the code to its design model.

CopyC2M

Add Method

AddMs Add an important method existing

in the code to its design model.

Add Field

AddFd Add an important ﬁeld existing in

the code to its design model.

Add Message

AddMsg Add an important message

send/receive (method call) ex-

isting in the code to its design

model.

Behavioral

Add API Call

AddAPI Add an important API call in the

code to its design model.

Add Object

AddObj Add an important object in the code

to its design model.

but also traceability between design and code. A stu-

dent can ﬂuidly go back and forth between design and

code by using the refactoring patterns.

3.1 Pattern Catalog

Table 2 shows the pattern catalog composed of

MoveM2C (Move concerns from Model to Code) and

CopyC2M (Copy concerns from Code to Model).

A pattern in the MoveM2C category moves a de-

sign concern to a code concern. This pattern is ap-

plied to the situation in which a design model has

to be changed frequently to reﬂect code change. It

may be preferable to locate the concern to code. As

another situation, this pattern can be temporarily ap-

plied if experimental coding is needed to ﬁnd an ap-

propriate design such as performance issues and cor-

rect API usages. After ﬁnding an adequate design,

the CopyC2M pattern category should be applied to

recover a design concern from its code. By apply-

ing the MoveM2C pattern, we can raise an abstraction

level. The abstraction of a design model becomes an

appropriate level and the design model becomes sta-

ble (not frequently modiﬁed). The MoveM2C cate-

gory is divided into two kinds of patterns: one is the

structural patterns for abstracting class structures and

includes RmCs, RmSubCs, RmLibCs, RmMs, RmFd

patterns. Another is the behavioral patterns for ab-

stracting message sequences and includes RmMsg,

RmAPI, RmObj patterns. These patterns are related

to each other. For example, if a message is removed

from a sequence diagram (RmMsg), we have to re-

move the target object (RmObj) and associated mes-

sage sequences (RmMsg). Moreover, we may have to

remove a class instantiating the object (RmCs), its sub

classes (RmSubCs), associated methods (RmMs), and

ﬁelds (RmFd) from a class diagram. Although each

pattern is simple, it is not easy to apply these patterns

while preserving the consistency. Our support tool

iArch can automate these tasks.

A pattern in the CopyC2M category copies a code

concern to a design concern. This pattern, the reverse

of the MoveM2C pattern, is applied to the situation

in which a student wants to change a design model

to reﬂect an important design concern that could not

be captured in the early phase but can be obtained in

the coding phase. By applying the CopyC2M pattern,

we can lower an abstraction level. To perform the

CopyC2M pattern efﬁciently, iArch supports the fol-

lowing: 1) a student selects a code region that should

be reﬂected to the corresponding design model; 2)

iArch shows the candidates of updated Archface de-

scriptions; 3) the student selects most appropriate one

from the candidates and modiﬁes it if necessary; 4) a

model editor in iArch updates a design model in order

to reﬂect the updated Archface. If the design model

already contains a design point related to a new arch-

point deﬁned in the updated Archface, the model edi-

tor simply reuses the design point.

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

432

㻳㼞㼍㼐㼡㼍㼘㻌㻭㼞㼏㼔㼒㼍㼏㼑䚷㻾㼑㼒㼕㼚㼑㼙㼑㼚㼠

㻹㼍㼗㼑㻌㼙㼍㼞㼗㼟㻌㼠㼛

㼕㼙㼜㼛㼞㼠㼍㼚㼠㻌㼜㼛㼕㼚㼠㼟㻍㻌

㻰㼑㼟㼕㼓㼚㻌㼙㼛㼐㼑㼘㻌㼣㼕㼠㼔㻌㼍㼚㻌㼍㼜㼜㼞㼛㼜㼞㼕㼍㼠㼑㻌

㼍㼎㼟㼠㼞㼍㼏㼠㼕㼛㼚㻌㼘㼑㼢㼑㼘

㻾㼑㼏㼛㼢㼑㼞

㻰㼑㼟㼕㼓㼚

㻾㼑㼏㼛㼢㼑㼞

㻰㼑㼟㼕㼓㼚

㻾㼑㻙㼓㼑㼚㼑㼞㼍㼠㼑

㻯㼛㼐㼑

㻾㼑㻙㼓㼑㼚㼑㼞㼍㼠㼑

㻯㼛㼐㼑

㻭㼞㼏㼔㼜㼛㼕㼚㼠㻌

㻿㼘㼕㼏㼕㼚㼓

㻯㼛㼜㼥㻯㻞㻹㻌

㻼㼍㼠㼠㼑㼞㼚㼟

㻹㼛㼢㼑㻹㻞㻯㻌

㻼㼍㼠㼠㼑㼞㼚㼟

㻭㼞㼏㼔㼜㼛㼕㼚㼠㻌

㻿㼘㼕㼏㼕㼚㼓

Figure 1: Gradual Archface Reﬁnement.

Figure 2: iArch IDE.

4 LEARNING ENVIRONMENT

Figure 1 illustrates the abstraction reﬁnement process

using MoveM2C and CopyC2M. This reﬁnement pro-

cess is supported by the iArch IDE (Ai et al., 2014)

consisting of the followings: 1) model editor, 2) pro-

gram editor, 3) Archface editor and generator, 4) ab-

straction metrics calculator, and 5) abstraction-aware

verifying compiler. Figure 2 is a snapshot of iArch

implemented as an Eclipse plug-in. 1) is class and se-

quence diagrams of the Observer pattern. 2) is a Java

program implementing the Observer pattern. 3) is an

Archface deﬁnition. We can automatically generate

initial Archface descriptions from a design model. 4)

shows the abstraction ratio of the Observer pattern.

5) is the output from the abstraction-aware verifying

compiler. This compiler generates error messages if

the traceability between a design model and code is

violated. The refactoring support facility is newly

added to the iArch IDE.

5 EXPERIMENT

We evaluated the effectiveness of our refactoring pat-

terns by applying them to a system developed in our

university class. Although this is a preliminary ex-

periment and we cannot assume the generality of the

result, it gives us an interesting intuition about teach-

ing software development in terms of abstraction.

5.1 System Overview

A web-based online book-shop system was devel-

oped in a PBL, a class for master students to learn

the methods and processes for developing a practical

system. The artifacts of this system consist of UML

models and programs written in Java and JavaScript.

We used class diagrams, sequence diagrams, and Java

programs as the target of this evaluation. This system

consists of two main functions. One is a function for

a shop user to search book information and check the

user ranking. Another is a function for a shop clerk to

manage book information. Table 3 shows the system

conﬁguration and its size (LOC: Lines of Code). The

software modules consist of 1) deﬁnition of the rela-

tion among modules (abs); 2) access control for the

database (asasecommon); 3) user service (web); and

4) clerk service (ofﬁce).

5.2 Research Questions

In this experiment, we addressed the following three

research questions: RQ1) How much value does an

abstraction level become in an educational project?;

RQ2) What becomes the trigger of applying the refac-

toring patterns?; and RQ3) Does an abstraction level

ﬁnally converge to a certain value by applying the

refactoring patterns?

RQ1 is intended to clarify whether or not some

kind of tendency is seen about the value of an ab-

straction level. It is considered that the abstraction

level varies according to a project theme and a target

domain. However, there may be the similar tendency

in a similar team or a similar PBL theme. Of course,

we cannot deﬁnitely give a predictable value of the

abstraction level, because it is just the evaluation by

one project. RQ2 is intended to clarify bad smells

that trigger a student to refactor a design model and

its code. RQ3 is intended to measure the effect of ap-

plying the refactoring patterns.

5.3 Experiment Results

RQ1: Table 4 shows the abstraction level of the on-

line book shop system. The value was about around

0.5 in the system development of the educational pur-

pose. This value may be slightly lower than that of

the system development in companies. We consider

that the value is appropriate because one of the pur-

poses of this educational PBL is to help students un-

Can Abstraction Be Taught? Refactoring-based Abstraction Learning

433

Table 3: Project Size of an Online Book Shop System.

Module Name Number of Classes Number of Class Diagrams Number of Sequence Diagrams LOC

abs 23 1 0 411

asasecommon

26 1 0 1393

web

9 1 2 244

ofﬁce

20 1 4 438

— — — 3170

Table 4: Initial Abstraction Level of the System.

ID Use Case (*) Archpoint Program Point Inconsistency Abstraction Ratio

u1 User: Check User Ranking 9 22

√

0.59

User: Search Book Titles 16 24 0.33

Clerk: Search/Update/Delete Publisher Information 31 76

√

0.59

Clerk: Register Publisher Information 12 24

√

0.5

Clerk: Search/Update/Delete Book Information 37 82

√

0.55

Clerk: Register Book Information 12 24

√

0.5

* Each use case is modeled using a sequence diagram.

Table 5: Bad Smells and Refactoring Patterns to be Applied.

ID Bad Smell Reason Refactoring Patterns

u1 B There is an inconsistency between a sequence dia-

gram and code, because the usage of API is changed.

RmAPI, RmObj, AddObj, AddMsg

A It is not necessary to distinguish the brief search and

the detailed search.

RmMsg

B A part of functions are not modeled in a sequence di-

agram.

AddObj, AddMsg, RmMsg

B Same as above. AddObj, AddMsg, RmMsg

A: Abnormal Abstraction Level, B: Inconsistency between Design and Code

Table 6: Change of Abstraction Level at Each Refactoring Step.

ID Refactoring Step

1: Recover Traceability between Design and Code 2: Apply CopyC2M 3: Apply MoveM2C

u1 RmAPI, RmObj / +0.09 AddObj, AddMsg / -0.05 —

— — RmMsg / +0.25

— AddObj, AddMsg / -0.12 RmMsg / +0.15

— AddObj, AddMsg / -0.12 RmMsg / +0.16

— AddObj, AddMsg / -0.11 RmMsg / +0.14

— AddObj, AddMsg / -0.12 RmMsg / +0.16

Legend: Applied Patterns / Change of Abstraction Level (Difference Before and After Refactoring)

derstand the traceability between a design model and

the code in terms of abstraction. It is easy for a stu-

dent to understand abstraction when a design model

is not too abstract and is relatively close to its code.

On the other hand, the student may fail to capture the

abstraction skills if the abstraction level is larger than

0.5. We consider that it is effective to suggest to stu-

dents that they should make a design model with the

abstraction level 0.5 as the ﬁrst learning step. Stu-

dents will ﬁnd more appropriate abstraction level after

they can understand the meaning of 0.5.

RQ2: In this experiment, students in the PBL class

extracted two kinds of bad smells that triggered the

application of the abstraction-aware refactoring pat-

terns: 1) Abnormal abstraction level; and 2) Incon-

sistency between design and code. 1) indicates that

refactoring is needed if a class or a method has an

exceptional abstraction ratio comparing other classes

or methods. 2) indicates the situation in which trace-

ability is not preserved between artifacts. Someone

may consider why 2) is a bad smell, because the trace-

ability has to be maintained in software development.

However, many student projects cannot necessarily

preserve the traceability, because it has to be main-

tained by hand in most cases. Current MDD tools

do not provide the functions for practical traceabil-

ity checking. If traceability is not maintained, de-

sign models tend to evolve without taking into ac-

count the code. As a result, the abstraction level of

the design model may become inadequate. Table 5

shows bad smells and refactoring patterns to be ap-

plied. In Table 4, the abstraction level of the use case

is 0.33. We cannot determine whether this value

is appropriate or not by checking only this value, al-

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

434

Abstraction

Ratio

Initial Step 1

Step 2 Step 3

Final

Figure 3: Change History of Abstraction Levels.

though one might consider the value is relatively low.

However,this value is exceptionallylow comparingto

the abstraction levels of other use cases whose func-

tionality is similar to that of the use case

. There

was a possibility of a bad smell. We checked the se-

quence diagram representing the use case

in detail

and found that a function “Search book information”

was divided into two use cases “brief search” and “de-

tailed search”. In this case, it is desirable to refactor

the sequence diagram representing

by applying the

RmMsg pattern. These bad smells help a student cap-

ture the practical skills for abstraction.

RQ3: In this PBL class, the students performed

three refactoring steps: 1) recover the traceability

link between a design model and code; 2) apply the

CopyC2M pattern; and 3) apply the MoveM2C pat-

tern as shown in Table 6 and Figure 3. All sequence

diagrams converged to the similar abstraction level.

The gap between maximum and minimum abstraction

level is changed from 0.26 (= 0.59-0.33) to 0.09 (=

0.63-0.54). Our refactoring patterns help a student re-

ﬁne and explore an appropriate abstraction level. The

student can understand that he or she can obtain a sim-

ple and beautiful software structure by seeking an ap-

propriate abstraction level.

6 RELATED WORK

Someone might wonder what is a distinction between

our approach and a view supported by many modeling

tools that can hide a portion of a model. If a developer

makes a detailed model equal to the code, an abstract

model can be obtained from the original model with-

out using our approach. However, a student cannot

get a skill for making an abstract model but write code

just using modeling notations. Moreover, in practical

development, it is not realistic to make a code-level

model, because the model is not only useless but also

difﬁcult to maintain.

As claimed in this paper, traceability between de-

sign and code plays an important role in teaching ab-

straction, because an abstract design model cannot

exist without considering the relation to its program

implementation. There are several studies on trace-

ability. T. D’Hondt et al. introduced LMP (Logic-

Meta Programming) to enforce the synchronization

between object-oriented design and code (D’Hondt

et al., 2001). H. Bagheri et al. showed a way for au-

tomated formal derivation of style-speciﬁc architec-

tures (Bagheriet al., 2010). Y. Zheng and R. N. Taylor

proposed 1.x-way architecture-implementation map-

ping (Zheng and Taylor, 2012) for deep separation of

generated and non-generated code. JaMoPP

, a set of

plug-ins for parsing Java code into models based on

EMF (Eclipse Modeling Framework), bridges the gap

between modeling and programming. MoDisco

is a

framework to develop model-driven tools supporting

software modernization. Both JaMoPP and MoDisco

provide reverse engineering facilities. In the past,

many ADLs (Architecture Description Languages)

have been proposed to describe an architectural de-

sign model at a high abstraction level. R. Allen and

D. Garlan proposed Wright (Allen and Garlan, 1994)

to formalize the component-and-connector architec-

ture. J. Aldrich et al. proposed ArchJava (Aldrich

et al., 2002), an extension of Java. ArchJava uniﬁes

architecture and implementation, ensuring that the

implementation conforms to architectural constraints.

Umple

supports the notion of model-oriented pro-

gramming that adds modeling features derived from

UML to object-oriented languages such as Java. Us-

ing ArchJava or Umple, we can merge modeling with

programming. Cassou et al. explored the design

space between abstract and concrete component in-

teraction speciﬁcations (Cassou et al., 2011).

However, these approaches do not support ﬂuid

moving while preserving abstraction. They take the

policy that separation of concerns between design and

code should be ﬁrmly determined at the initial design

phase. However, we often observe ﬂuid moving and

frequent change of abstraction in educational projects

as repeatedly claimed in this paper, because an ordi-

nary student cannot create a well-abstract design at

the initial phase. It is necessary to provide a method

for supporting ﬂuid moving in the light of abstraction.

Our proposal is one of the solutions for dealing with

this educational challenge.

Automated veriﬁcation tools supporting formal

speciﬁcations are useful for students to capture their

abstraction skills, because the repeated cycle of trial-

and-error development gives the students opportuni-

ties of rethinking the abstract speciﬁcations. For ex-

http://www.jamopp.org/

http://www.eclipse.org/MoDisco/

http://cruise.eecs.uottawa.ca/umple/

Can Abstraction Be Taught? Refactoring-based Abstraction Learning

435

ample, the Alloy analyzer (Jackson, 2006) is suitable

for students to understand the essence of software ab-

stractions. Our abstraction-aware verifying compiler

helps a student understand the traceability between

design and code in terms of abstraction.

7 CONCLUSIONS

In this paper, we showed that refactoring crosscutting

over design and code is effective for ordinary students

to learn software abstractions. However, many educa-

tional challenges still remain, because abstraction is

a philosophical deep concept. Our deﬁnition of ab-

straction (removal of details) is based on archpoints,

a simple mechanism for not only representingabstrac-

tion but also realizing traceability. However, abstrac-

tions existing in a real software development project

are not limited to the concepts in which design points

and program points are mapped each other. Never-

theless, we consider our approach is effective for ed-

ucational purposes, because it can integrate many im-

portant notions such as deﬁnition of abstraction level,

traceability check, and refactoring both design mod-

els and code.

Although this paper focused on the educational as-

pect in university, we expect that our approach can be

applied to leverage the modeling skills of primary en-

gineers. The lack of proper skills for abstraction is a

real problem in industry. The ﬁrst author of this paper

worked in industry as a software engineer for twenty

years before moving to academia. To tell the truth,

this research is motivated by the author’s experience

in industry. We believe that a systematic method for

improving abstraction skills is one of the most impor-

tant issues both in academia and industry. Unfortu-

nately, such a method does not exist yet. Our pro-

posal is a ﬁrst step towards method development for

improving abstraction skills.

ACKNOWLEDGMENTS

We thank Di Ai, Peiyuan Li, Yuning Li, and Zhongx-

iao Guo for their great contributions. They were stu-

dents of our university. They implemented the iArch

IDE. Di Ai assisted the evaluation shown in Section 5.

This work was supported by JSPS KAKENHI Grant

Numbers JP26240007, JP25540025.

REFERENCES

Ai, D., Ubayashi, N., Li, P., Hosoai, S., and Kamei, Y.

(2014). iarch: An ide for supporting abstraction-aware

design traceability. In Proceedings of the 2nd In-

ternational Conference on Model-Driven Engineering

and Software Development (MODELSWARD 2014),

pp.442-447.

Aldrich, J., Chambers, C., and Notkin, D. (2002). Archjava:

Connecting software architecture to implementation.

In Proceedings of the 24th International Conference

on Software Engineering (ICSE 2002), pp.187-197.

Allen, R. and Garlan, D. (1994). Formalizing archi-

tectural connection. In Proceedings of the 16th

International Conference on Software Engineering

(ICSE’94), pp.71-80.

Bagheri, H., Song, Y., and Sullivan, K. J. (2010). Architec-

tural style as an independent variable. In Proceedings

of the 25th IEEE/ACM International Conference on

Automated Software Engineering (ASE 2010), pp.159-

162.

Batini, C. and Viscusi, G. (2016). Er2016 - tutorial on ab-

stractions in conceptual modelling and surroundings.

Cassou, D., Balland, E., Consel, C., and Lawall, J. (2011).

Leveraging software architectures to guide and ver-

ify the development of sense/compute/control appli-

cations,. In Proceedings of the 33rd International

Conference on Software Engineering (ICSE 2011),

pp.431-440.

D’Hondt, T., Volder, K. D., Mens, K., and Wuyts, R. (2001).

Co-evolution of object-oriented software design and

implementation. In Software Architectures and Com-

ponent Technology, pp.207-224. Kluwer Academic

Publishers.

Egyed, A., Letier, E., and Finkelstein, A. (2008). Gener-

ating and evaluating choices for ﬁxing inconsistencies

in uml design models. In Proceedings of the 23rd In-

ternational Conference on Automated Software Engi-

neering (ASE 2008), pp.99-108.

Fowler, M. (1999). Refactoring: Improving the Design of

Existing Code. Addison-Wesley.

Jackson, D. (2006). Software Abstractions: Logic, Lan-

guage, and Analysis. The MIT Press.

Kramer, J. (2007). Is abstraction the key to computing? In

Communications of the ACM, Vol. 50 Issue 4, pp.36-

42.

Magee, J. and Kramer, J. (2006). Concurrency: State Mod-

els and Java Programs. Wiley.

Shaw, M. and Garlan, D. (1994). Characteristics of higher

level languages for software architecture. In Techni-

cal Report, CMU-CS-94-210. Carnegie Mellon Uni-

versity.

Taylor, R. N. and Hoek, A. (2007). Software design and ar-

chitecture –the once and future focus of software en-

gineering. In Proceedings of 2007 Future of Software

Engineering (FOSE 2007), pp.226-243.

Ubayashi, N., Ai, D., Li, P., Li, Y., Hosoai, S., and Kamei,

Y. (2014). Abstraction-aware verifying compiler for

yet another mdd. In Proceedings of the 29th Interna-

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

436

tional Conference on Automated Software Engineer-

ing (ASE 2014), New Ideas Paper, pp.557-562.

Zheng, Y. and Taylor, R. N. (2012). Enhancing architecture-

implementation conformance with change manage-

ment and support for behavioral mapping. In Proceed-

ings of the 34th International Conference on Software

Engineering (ICSE 2012), pp.628-638.

Can Abstraction Be Taught? Refactoring-based Abstraction Learning

437