TEACHING ABSTRACTION IN MATHEMATICS

AND COMPUTER SCIENCE

A Computer-supported Approach with Alloy

M. Simonot, M. Homps and P. Bonnot

LIASD, Universit

e Paris 8- IUT Montreuil, 140 Rue de la Nouvelle France, 93100 Montreuil, France

Keywords:

Abstraction, Alloy, Lightweight Formal Method, Modelling, Teaching Mathematics for Computing, Computer

Supported Education.

Abstract:

Abstraction skill is difﬁcult but essential when learning computer science and mathematics. In this paper, we

present an experience from the Computer Science Department of IUT de Montreuil in which mathematics

and computing teaching work together in order to provide abstract thinking skills to students. Our approach

is to connect mathematics and software engineering through a computer-supported approach which uses - in

mathematics and software engineering undergraduate courses- Alloy, a lightweight formal method from MIT.

Alloy serves as a continuum from micro-modelling activities -used to enforce an abstract understanding of

basic mathematic concepts- to real software modelling practice. It enables us to elaborate a kind of exploratory

learning where students are actively engaged.

1 INTRODUCTION

Abstraction is a vital skill when learning Computer

Science as well as Mathematics. Keith Devlin (De-

vlin, 2003) explains clearly the importance of ab-

straction for Computer Science : “ Once you real-

ize that computing is all about constructing, manip-

ulating, and reasoning about abstractions, it becomes

clear that an important prerequisite for writing (good)

computer programs is the ability to handle abstrac-

tions in a precise manner“. But learning abstraction is

hard and many students tend to stay at a low level of

abstraction, focusing immediately on the code rather

than the design.

The need for abstraction gives to mathematics

course an important part of computing curriculum.

But many students have a negative attitude.

Observing this difﬁculties raise the following

question: how mathematics and computing can work

together in order to provide abstract thinking skills to

students?

In this paper we address this question. As we

are concerned with Computer Science curriculum, our

ﬁrst choice was to concentrate on software modelling

and on discrete mathematics, logic and sets. Indeed,

software modelling is a good way to practice ab-

straction and discrete mathematics is its mathematical

background. In order to connect as soon as possible

mathematical concepts with Computer Science, our

second choice was to introduce mathematical notions

with some kind of micro-modelling activities where

students use these notions to express things.

But in order to appropriate the notions our stu-

dents must take an active part. To address this

problem our third choice was to adopt a computer-

supported approach. with the help of Alloy (Jackson,

2006) (Alloy, 2007), a lightweight formal method

dedicated to rapid software modelling created by

Daniel Jackson’s, group at MIT. This tool allows us to

elaborate a pedagogy based on the Actions-Process-

Object model (Fenton and Dubinsky, 1996) which is

considered today as the central model of concept for-

mation.

Our proposal can be summarized as follows : our

approach is to connect mathematics and software en-

gineering through the use- in mathematics and soft-

ware engineering courses- of Alloy. Alloy serves as

a continuum from micro-modelling activities -used

to enforce an abstract understanding of basic math-

ematic concepts- to real software modelling practice.

This leads us to reorganize our curriculum as fol-

lows : the ﬁrst mathematics course of our curriculum

is devoted to logic, sets functions and relations, in-

duction . . . . Every time a notion is introduced, the

students have an Alloy laboratory session whose role

is the appropriation of this new notion. Laboratory ex-

239

Simonot M., Homps M. and Bonnot P..

TEACHING ABSTRACTION IN MATHEMATICS AND COMPUTER SCIENCE - A Computer-supported Approach with Alloy.

DOI: 10.5220/0003898302390245

In Proceedings of the 4th International Conference on Computer Supported Education (CSEDU-2012), pages 239-245

ISBN: 978-989-8565-07-5

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

ercises are elaborated following the APO model. At

the end of the course, as students familiarize them-

selves with the notions and the tool, some laboratory

sessions are devoted to introduce them to a model

driven approach of software engineering and to give

them a mathematical representation of key concepts

of computing such as inheritance, composition, ab-

stract classes . . .

Alloy is then from time to time used in Com-

puter science courses such as programming language,

database relational model, Uml modelling, when in-

troducing computing concepts or formalisms and in

order to give them a mathematical meaning. In this

way, the work made with mathematics and Alloy

doesn’t substitute for usual computing topics. It im-

proves them by giving them a common language.

The cross-disciplinary characteristic of Alloy labs

requires a mixed teaching team. Our team is com-

posed of 2 mathematics and one computing teacher.

Each lab session is elaborated in common and taught

in parallel.

2 RELATED WORKS

Computer-supported approach has been extensively

used in mathematic education in order to enforce stu-

dents motivation and to develop an active attitude.

A common approach is to use web technology as in

(Gregory, 2004). Other works (Siller and Greefrath,

2009) share with us a focus on mathematical mod-

elling but most of them use software tools as Com-

puter Algebra systems (CAS), Dynamic Geometry

Software (DGS) or Spredsheet programs (SP). Our

approach is very closed from (Fenton and Dubinsky,

1996). We adopt their APO model of concept for-

mation together with a computer-supported approach

The main differences are (1) that we use a lightweight

formal method while they use a programming lan-

guage, (2) that our approach doesn’t restrict to mathe-

matics but is cross-disciplinary. We use the same tool

to enforce an abstract understanding of basic math-

ematic concepts as well as to practice real software

modelling.

The idea to introduce Object-Oriented concepts

with the preliminary use of a modeling language is

also present in (Hadar and Hadar, 2007). In this paper,

authors insist on two properties of UML : abstraction

barrier and visual representation. Those properties are

also properties of Alloy and have motivate our choice.

The use of UML for Object-oriented concepts intro-

duction is also present in (Bennedsen and Caspersen,

2004). UML and Alloy serve the same goal : let the

students have the “big picture” of programs, but the

use of Alloy lets also the students have a mathemati-

cal understanding of O.O concepts.

The belief that the main intellectual challenge of

software engineering is abstraction and design is com-

monly shared and leads a lot of institutions to intro-

duce formal methods as soon as possible in under-

graduate curriculum. (Sotiriadou and Kefalas, 2000)

describes a formal method course in the second year

of the undergraduate curriculum which focuses on

software modelling and uses the Z formal speciﬁca-

tion language. In Rochester Institute of Technology

(RIT) (Lutz, 2006), (Naveda et al., 2009) the soft-

ware engineering program has been redesigned in or-

der to expose students to both formal and informal

modelling throughout the entire curriculum. Discrete

mathematics take place in the ﬁrst year and formal

methods for speciﬁcation and design such as Z, VDM,

and more recently Alloy are introduced as soon as

possible.

In (Boyatt and Sinclair, 2008) a software design

undergraduate module which uses Alloy is described.

Like us, they highlight two characteristics of Alloy:

experiment and visualization which help shape the

mathematical understanding of a model and allow a

kind of exploratory learning. The fact that the use

of Alloy is compartmentalized in one module is men-

tioned in the paper as a limit of their approach. To this

effect, We can say that our work extends this work be-

cause of our use of Alloy as a continuum from mathe-

matic concepts learning to software design modelling.

Few works address our problem of how to decom-

partmentalize mathematics and computing learning.

We can cite (Sekerinski, 2009) where mathematics

is used as the unifying force of all core elements of

software design. But, in this approach the focus is

placed on speciﬁcations, algorithms and correctness

proofs with the use of Weakest Preconditions Calcu-

lus while we focus on mathematical modelling. We

can also cite (Cohoon and Knight, 2006) which de-

scribes efforts made at Virginia University to connect

software engineering and discrete mathematics. Their

solution differs from ours: they systematically moti-

vate introduction of discrete mathematic notions by

preliminary software engineering problem studies.

3 ALLOY

Like all formal method, Alloy is made of a language

and a tool which supports the language. An Alloy text

(a model) is made of sets and relations deﬁnitions and

of formulas expressing constraints over them. But

Alloy is a lightweight formal method i.e. a method

which has a formal basis but is limited in its scope.

CSEDU2012-4thInternationalConferenceonComputerSupportedEducation

240

The limitation of Alloy is in the analyzer support-

ing the language: it uses SAT solving techniques to

check the model. The analyzer therefore doesn’t pro-

vide general results as theorem proving does, but it

gives a quick way of exploring instances of the model

and generating counterexamples.

Alloy provides two commands: run and check.

With the run command, Alloy tries to ﬁnd instances

which satisfy deﬁnitions and constraints of the model.

If it succeeds, satisﬁability of the model is proved, but

if it fails, we don’t have guarantee of unsatisfability.

The check command is used to check if a given for-

mula is a consequence of the model. In this case, The

analyzer tries to ﬁnd a counterexample. A success

proves that the assertion is wrong, a failure doesn’t

prove anything.

Let us illustrate Alloy with a simple example, in-

spired from the famous scene of the Sergio Leone’s

ﬁlm: the good, the bad and the ugly:

-“You see, in this world, there are two kinds of peo-

ple, my friend : those with loaded guns and those who

dig. You dig.”

We need a Human set partitioned by 2 disjoint sub-

sets GunMan and Digger and also a Hole set and a

Treasure set. We deﬁne 3 relations in order to ex-

press the facts that gunmen threats diggers, that dig-

gers dig holes and that holes contains treasures. The

Alloy model is given in listing 1.

Listing 1: The gunman model.

s i g Hole { c o n t a i n : l on e T r e a s u r e }

s i g T r e a s u r e {}

a b s t r a c t s i g Human{}

s i g D i g g er e x t e n ds Human{ d i g : s e t Hol e }

s i g Gunman e x t e n d s Human{ t h r e a t : s e t D i gg e r }

Figures 1(a) shows an instance obtained with

the Run command. Our model, doesn’t enforce

the contain relation to be injective. Execut-

ing check{injective[contain,Treasure]} will

produce counterexamples as shown in ﬁgure 1(b).

4 LEARNING MATHEMATIC

NOTIONS WITH THE HELP OF

ALLOY

4.1 Visualization and Active Learning

Alloy doesn’t prove anything but provides a quick

way of exploring instances of models, generating

counterexamples and visualizing the results. In other

(a) (b)

Figure 1: An instance (a) and a counterexample (b).

words, the tool shows a representation of what the stu-

dent has written. The teacher can then adopt an atti-

tude where he never gives the answer to an exercise

but helps the student to ﬁnd how the tool will give

it. This kind of iterative interaction with the tools im-

poses active learning, let the student be responsible

for what he says and allows him to interiorize the no-

tions.

4.2 A Constructivist Approach

In this section, we will explain how Alloy allows a

pedagogy based on the Action-Process-Object model

(Fenton and Dubinsky, 1996) which is considered to-

day as the central model of concept formation.

According to this model, three successive mental

constructions are needed in order to develop an under-

standing of a mathematical concept. At the ﬁrst stage,

the learner performs actions on object, according to a

given algorithm. When the learner gains the ability to

refer to these actions using symbols or is able to imag-

ine the action without needing to perform it explicitly,

we say that the actions were transformed into a pro-

cess. The last stage is transforming the process into

an object: the learner can refer to the entity concept

much like he refers to a physical entity.

Let us consider again our GunMan example in

order to illustrate the elaboration of exercises corre-

sponding to the three stages of the APO model dedi-

cated to the learning of relation concept.

According to APO model, at the beginning of the

learning process, students need to work on concrete

examples and to follow step by step instructions. For

this purpose, it is convenient to work with a ﬁx in-

stance of the model. Let us then add the Alloy text

of listing 2 to the model-listing 1 in which sets and

relations are extensionally deﬁned:

TEACHINGABSTRACTIONINMATHEMATICSANDCOMPUTERSCIENCE-AComputer-supportedApproach

withAlloy

241

Listing 2: A ﬁx instance of gunman model.

one s i g c h e s t , n u g g e t e x t e n d s T r e a s u r e {}

one s i g t heBad , t he U gl y e x t e nd s D ig g e r {}

one s i g theGood , o t h e r e x t e n d s Gunman{}

one s i g h1 , h2 , h3 e x t e n d s Hole {}

f a c t {

c o n t a i n = h1−>c h e s t + h2−>n u g ge t &&

t h r e a t = the Goo d−>t h e U gl y + the Good−>t h e B a d +

o t h e r −>t h e B a d &&

d i g = t heBad−>h1 + t h e U g l y−>h3 + t h eBad−>h3

}

We can then ask the students to perform step by

step the compose deﬁnition and to interact with Alloy

for self-assessment as in the following exercise:

Exercise 1. Add the following 2 sentences to the

GunMan model and complete the mystery fact by

giving the tuples corresponding to the compose of

dig and contain:

fact mystery{ m1= //to be completed}

check { m1= dig.contain}

After the deﬁnition has been processed, we can

move to a little more abstract level as in the following

exercise.

Exercise 2. Add the following 2 sentences to the Gun-

Man model and give a meaningful name to m2. You

can have help by exploring instances with Alloy:

fact { m1= dig.contain}

fact { m2= threat.m1}

Understanding m2 supposes to take m1 as a whole,

as an object. To be able to give a meaningful name to

m2 (for instance possess), requires then a mental rep-

resentation of m2, i.e. of the compose concept itself.

Alloy visualization of instances and work in auton-

omy contributes strongly to this process.

The next step is to ask students to deﬁne their own

relations.

Exercise 3. Deﬁne the threatWith relation which

maps gunmen to gunmen who threat at least a same

person. Is your relation reﬂexive (to be test with Al-

loy)? How to proceed if we don’t want it to be reﬂex-

ive?

At this stage, students must be able to combine re-

lations in order to deﬁne a new one. Contrary to the

other steps, Alloy will be helpful only after they have

formulated a deﬁnition, as a test tool. Moreover they

are engaged in an iterative (micro-)modelization pro-

cess: using mathematic notions to express concrete

phenomenons.

Previous exercises work on concrete relations. It

is now time to free from them. Three kinds of activ-

ities are provided: Analyze of given models, model

design and mathematical problems. The ﬁrst and the

second will be detailed in the next section. Mathemat-

ical problems are the way to connect the work done in

Alloy laboratory sessions with traditional paper and

pencil mathematic sessions. Here is an example:

Exercise 4. Is a symmetric and transitive relation

necessary reﬂexive? Use Alloy to check your guess

and then prove it on a paper.

We evaluate student’s ability to build an interac-

tion with Alloy in which the student role is restricted

to the formulation and the investigation of the prob-

lem. Alloy counterexamples should lead to under-

stand that only a total symmetric and transitive rela-

tion is necessarily reﬂexive. It can be ﬁrst checked

with Alloy and then proved on paper.

5 A MODELLING-FIRST

APPROACH OF COMPUTING

As soon as students have acquired the basic mathe-

matical notions, they are able to model simple soft-

ware systems with Alloy. To begin software mod-

elling in the math course is interesting because in

math course students don’t ask for writing code. Stu-

dents don’t balk at doing such exercises because they

see the connection with computing. Furthermore,

modelization is an abstraction process and modeliza-

tion exercises are a perfect way to practice abstrac-

tion. From the computer science point of view, it

allows to expose our students to software modelling

from the beginning of our curriculum and to give a

mathematical intuition of basic concepts of comput-

ing.

5.1 Introducing Object Oriented

Notions

Let us take the example of a static description of a

multimedia library. Such a library has several media.

Each media has a unique reference, a unique title and

a unique borrower. Different media must have dif-

ferent reference. This exercise which is a standard

UML exercise can be modelled with Alloy with the

basic mathematical notions previously used as shown

in listing 3.

As it can be noticed, Alloy language has been

elaborated in order to be mathematically simple and

CSEDU2012-4thInternationalConferenceonComputerSupportedEducation

242

Figure 2: Multi media library with meta model and in-

stance.

also to be closed to object programming and mod-

elling language. We deﬁne sets and relations over

sets, but it looks like class and instance variables. In

fact, it gives a mathematical semantic of object lan-

guage.

Listing 3: Multi media library model.

s i g MMLib{

med i a s : s e t Medium

}

a b s t r a c t s i g Medium{

r e f e r e n c e : one Ref ,

b o r r o w e r : l o n e P e r s o n

}

f a c t { i n j e c t i v e [ r e f e r e n c e , R ef ] }

s i g P erson , Ref , Time{}

s i g Book e x t e n d s Medium{

nbPa ge : one I n t

}

s i g Music e x t e n d s Medium{

d u r a t i o n : one Time

}

When students will be introduced to object program-

ming, they will have this kind of mathematical intu-

ition to engage with the subject.

The same work can be done with inheritance as

shown in listing 3. The Alloy keyword extends has

been ﬁrst explained with notions like inclusion, parti-

tion and disjoint subsets. When students will be intro-

duced to inheritance, they will be able to look at in-

heritance as inclusion. This is the key for a good use

of inheritance in object conception, for understanding

that subclasses inherit instance variables and methods

from super-classes, and to understand Liskov Substi-

tution Principle.

There is also a strong connection between UML

class diagram and meta-models generated by Alloy,

as illustrated by ﬁgure 2. Our use of Alloy let students

have a uniﬁed view of programming and software de-

sign. Lastly, the generated instances of software mod-

els such as the second box of ﬁgure 2 help to consider

an object program as a graph, i.e. as a set of related

objects which cooperate. Introduction of notions as

responsibility delegation will be easier.

5.2 Introducing Theoretical Aspects of

Computing

As Alloy is a formal method, it obviously allows to

introduce theoretical notions such as speciﬁcations,

Pre/Post conditions, system invariant, algorithm re-

ﬁnement of speciﬁcations, ﬁnite state machines and

so on. Each of these topics relies on the possibility to

model the dynamic of a system. In this case, Alloy vi-

sualisation provides is a kind of symbolic execution of

the system which allows to test speciﬁcations. One of

the key point is that these notions can be introduced in

a simple way and without the need of proofs. Students

are in this way exposed to a declarative approach of

computing.

6 ASSESSMENT

In this section we will analyze to what extent we have

achieved our goals.

Is Alloy Really Simple to Use? One of our hypoth-

esis was the fact that Alloy, from our point of view,

seemed to be very simple to use. This point is con-

ﬁrmed. We didn’t provide any lessons devoted to the

use of the tool nor Alloy tutorial lab sessions. The

use of Alloy was explained degree by degree along

lab sessions devoted to mathematical exercises. The

most difﬁcult issue for students is to engage interac-

tion with the tool. We relate this fact with the question

of active learning and explain it in the next subsection.

Does Computer Supported Education with Alloy

Help Active Learning? We have insisted all over

this paper that simplicity and visualization tool of-

fered by Alloy is a key point for active learning. The

teacher never gives the response to an exercise but

helps the student to ﬁnd the way Alloy will give it.

It is in our opinion a key point to let the students be

active. But active learning -even with a well adapted

tool as Alloy- had to be imposed. Students resist to

engage in this kind of self exploratory learning and

teachers have to struggle in order to impose it. Fur-

thermore, our hypothesis that students will enjoy do-

ing maths with computer turns out to be false. More

precisely, Alloy labs students assessment follows a

cycle. They enjoy in the beginning, they don’t like

when they realize that it requires to be active and it is

better at the end when they get accustomed. We think

that the reasons are: (1) to be active needs efforts, (2)

TEACHINGABSTRACTIONINMATHEMATICSANDCOMPUTERSCIENCE-AComputer-supportedApproach

withAlloy

243

doing maths with Alloy is forgetting calculus and fo-

cusing on concept meaning. It is precisely what our

students rarely do before, and what is needed after. In

conclusion, despite the difﬁculties inherent to active

learning, our experience convince us to the relevance

of our approach.

Does Our Computer-supported Approach Help

Mathematic Education? One of our goals was to

enforce a deep understanding of basic mathematical

concepts. During Alloy labs, students manipulate

these basic notions as explained in section 4. This

kind of session is well achieved by a large part of stu-

dents. Moreover, encountered difﬁculties relate most

of the time to a real mathematic difﬁculty and very

rarely to an Alloy speciﬁcity : quantiﬁer alternations,

implication . . . . In exams, Alloy exercises are gen-

erally well achieved. From this point of view, Al-

loy labs allow us to insist on difﬁcult points and on

the necessity to master basic concepts. The point that

needs to be improved is the connection with the usual

paper and pencil mathematic activity. Even if Al-

loy labs are inside the mathematic course, even if we

elaborate exercises which show the connection and

even if teachers point out connections during lessons,

students tend to compartmentalize usual mathematics

and Alloy activity. We think that the reason is that

seeing connections needs to master the ﬁeld and it has

convinced us to work on many more decompartmen-

talizations.

Does Our Approach Help Computing Education?

The question of the connection between mathemat-

ics and computing was asked to the students and sur-

prisingly, a lot of them answered positively. It con-

vinces us to the relevance of : (1) beginning with logic

sets and discrete mathematics, (2) having a team com-

posed with both mathematic and computing teachers,

(3) using mathematic to model software systems. No

doubt, placing mathematical modeling in mathematic

course is efﬁcient. It is very surprising to see students

writing mathematical model docilely in math courses

while they balk at writing UML model in usual soft-

ware engineering courses Our approach doesn’t com-

pletely remedy the student dislike to abstract design of

software. Students prefer writing code to modelling

but, due to our experience, they have better abstract

skills for modelling and they know, because they prac-

tice models from the beginning of their studies that it

cannot be ignored.

7 CONCLUSIONS

We have described in this paper a computer-supported

experience from the Computer Science department of

IUT de Montreuil-Paris 8, whose goal is to connect

mathematics and software engineering through the

use-in mathematics as well as in software engineering

course- of the lightweight formal method Alloy. Al-

loy serve as a continuum from micro-modelling activ-

ities -used to enforce an abstract understanding of ba-

sic mathematic concepts- to real software modelling

practice. We explained our original use of this tool

for teaching mathematic concepts following the APO

model and for introducing O.O. concepts.

In conclusion, we think that our approach bene-

ﬁts to Mathematics as well as to Computer Science:

from the Mathematics point of view, the break with

methods used before in math teaching gives a boost

and develops problem solving skills. From the com-

puter scientist point of view, it allows to expose our

students to software modelling from the beginning of

our curriculum , as it is recommended by many cur-

rent approaches, in order to move our students from

procedural thinking to abstract one.

REFERENCES

Alloy (2007). The alloy analyzer. http://alloy.mit.edu.

Bennedsen, J. and Caspersen, M. E. (2004). Program-

ming in context: a model-ﬁrst approach to cs1. In

SIGCSE’04, pages 477–481.

Boyatt, R. and Sinclair, J. (2008). Experiences of teaching

a lightweight formal method. In Formal Methods in

Computer Science Education 2008.

Cohoon, J. and Knight, J. (2006). Connecting discrete

mathematics and software engineering. In 36th

ASEE/IEEE Frontiers in Education Conference, pages

13–18.

Devlin, K. (2003). Introduction. Commun. ACM, 46:36–39.

Fenton, W. E. and Dubinsky, E. (1996). Introduction to

discrete mathematics with ISETL. Springer.

Gregory, P. (2004). Motivating computing students to learn

mathematics. MSOR Connections, 4(3).

Hadar, I. and Hadar, E. (2007). An iterative methodology

for teaching object oriented concepts. Informatics in

Education, 6(1):67–80.

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

guage and Analysis. The MIT Press.

Lutz, M. (2006). Experiences with alloy in undergraduate

formal method. In Proceedings of 2006 American So-

ciety of Engineering Education Conference,, Chicago,

IL. June 2006.

Naveda, J. F., Lutz, M. J., Vallino, J. R., Reichlmayr, T.,

and Ludi, S. (2009). The road we’ve traveled: 12 years

of undergraduate software engineering at the rochester

institute of technology. In ITNG, pages 690–695.

Sekerinski, E. (2009). Teaching the unifying mathematics

of software design. In WCCCE ’09: Proceedings of

CSEDU2012-4thInternationalConferenceonComputerSupportedEducation

244

the 14th Western Canadian Conference on Comput-

ing Education, pages 109–115, New York, NY, USA.

ACM.

Siller, H. S. and Greefrath, G. (2009). Mathematical mod-

elling in class regarding to technology. In CERME 6.

Sotiriadou, A. and Kefalas, P. (2000). Teaching formal

methods in computer science undergraduates. In In-

ternational Conference on Applied and Theoretical

Mathematics.

TEACHINGABSTRACTIONINMATHEMATICSANDCOMPUTERSCIENCE-AComputer-supportedApproach

withAlloy

245