Teaching Design-by-Contract for the Modeling and Implementation of

Software Systems

Mert Ozkaya

Department of Computer Engineering, Yeditepe University, Istanbul, Turkey

Keywords:

Java Modeling Language, Defensive Programming, Design-by-Contract, Education.

Abstract:

Defensive programming is considered as a software design approach that promotes the reliable software devel-

opment via the considerations of different cases for the software modules. Design-by-Contract (DbC) applies

defensive programming systematically in terms of contracts that are a pair of pre-conditions on the module in-

put and post-conditions on the module output. In this paper, a DbC-based teaching methodology is proposed,

which aims to teach undergraduate students how to use contracts for the modeling and implementation of soft-

ware systems. The teaching methodology consists of three consecutive steps. Firstly, the students will learn

how to model software architectures in terms of components and their communication links. The component

behaviours are speciﬁed as contracts, which are attached to the messages that the components exchange. In

the second step, the students will learn how to implement the contractual software architectures in Java us-

ing Java’s assertion mechanisms in a way that the contractual design decisions are all preserved in the code.

Lastly, the students will learn the Java Modeling Language for combining the contractual modeling and Java

implementation in a single model to avoid any inconsistencies between the model and implementation and

automatically verify the correctness of the implementation against the modeled behaviours.

1 INTRODUCTION

Defensive programming is a software design tech-

nique for ensuring that software systems are devel-

oped with the considerations of different cases that

the systems can be in. This is also considered as im-

plementing the software modules in a way that the

different input cases for a module are always checked

before the module operates and the output is gen-

erated accordingly after the module call. By do-

ing so, the reliability of software systems can be en-

hanced as the failures in unexpected cases will be

minimised. Meyer proposed the Design-by-Contract

(DbC) approach in the early nineties for addressing

defensive programming in a systematic way (Meyer,

1992). DbC is based on the notion of contracts, which

describes the obligations and beneﬁts for the client

and supplier of a module. That is, whenever the

client satisﬁes some obligations on a software mod-

ule, the supplier of the module guarantees some ben-

eﬁts for the clients. DbC is formally based on the

Hoare logic (Hoare, 1969), which deﬁnes a contract

for a software module in terms of the pre- and post-

conditions. The Hoare logic states that whenever the

caller (i.e., client) of the software module satisﬁes the

pre-condition, the module computation can be per-

formed and then the post-condition shall be satisﬁed

by the supplier of the software module.

To apply DbC in software development, Meyer

proposed Eiffel (Severance, 2012) as a contract-based

language for analysing, designing, implementing, and

maintaining object-oriented software systems. Fol-

lowing Eiffel, Java Modeling Language (JML) (Leav-

ens et al., 2008; Cok, 2011) has been proposed for

combining the contractual speciﬁcations with the Java

implementation. Spec# (Barnett et al., 2011) applies

contracts for the C# programming language. Also,

there are some contract-based software architecture

description languages, such as XCD (Ozkaya and

Kloukinas, 2014), CBabel (Rademaker et al., 2005),

and RADL (Reussner et al., 2003).

In this paper, the goal is to teach students how

they can use DbC in their software development to en-

hance the reliability of software systems by means of

considering the different cases of the software mod-

ules and closing the gap between the software model

and implementation. So, a new teaching methodology

is aimed to be proposed that prompts the students to

model their software architectures contractually and

implement their software systems in a way that meets

the contractual model and enables the use of any tools

Ozkaya, M.

Teaching Design-by-Contract for the Modeling and Implementation of Software Systems.

DOI: 10.5220/0007950904990507

In Proceedings of the 14th International Conference on Software Technologies (ICSOFT 2019), pages 499-507

ISBN: 978-989-758-379-7

499

for checking the consistency between model and im-

plementation. The proposed teaching methodology

consists of three consecutive stages. First, the stu-

dents are taught how to specify the contractual soft-

ware architectures in terms of components that in-

teract with each other by sending/receiving messages

whose behaviours are speciﬁed as contracts. Second,

the students are taught how to implement the contrac-

tual software architectures in Java where the message

contracts are preserved in code via the Java assertion

mechanism. Third, the students are taught to use the

JML language for combining the contractual model-

ing with Java programming so as to minimise any in-

consistencies between the model and implementation

and thus maximise the reliability of software systems.

In the rest of the paper, the similar works are in-

troduced initially. That is followed by the introduc-

tion of the stages that comprise the proposed teaching

methodology. Next, the application of the methodol-

ogy on the gas station case-study is discussed. Lastly,

the evaluation of the methodology via an undergradu-

ate course is discussed.

2 RELATED WORK

The literature includes many studies that focus on

teaching software engineering or its sub-disciplines

(e.g., software modeling and software testing). These

studies propose new teaching methodologies, share

teaching experiences, or use some well-known tech-

niques for teaching software engineering. However,

none of them focus on teaching how to model and im-

plement software systems using the DbC approach.

Concerning the studies on software engineering,

in (Claypool and Claypool, 2005), the authors ex-

tended the software engineering course syllabus at the

University of Massachusetts, Lowell with game de-

velopment to maximise the students’ understanding

on the software engineering concepts, project man-

agement facilities, and computer game design. In

(Gnatz et al., 2003), the authors proposed the involve-

ment of customers in software projects performed by

the students and thus make them better understand the

real concerns of software projects, including the com-

munication, technical, management, and documenta-

tion issues. In (Alfonso and Botia, 2005), the authors

promoted the agile process model for the software en-

gineering course and encourage students to develop

software projects iteratively in terms of the inception,

elaboration, construction, and transition stages. In

(LeJeune, 2006), the author taught a group of students

the extreme programming features such as user sto-

ries, change management, testing, refactoring, etc.

Concerning the courses on software modeling, in

(Tamai, 2005), the author discussed how to teach

multiple software modeling techniques (e.g., UML,

ER modeling, Petri net, and state chart) that pro-

mote the modeling of software systems with com-

ponents and their relations but differ in the level of

abstractions and the models being dynamic or static.

In (Starrett, 2007), the author focused on teaching

high-school students the essense of modeling and ab-

straction via UML for improving their problem solv-

ing skills. In (Powell, 2001), the author focused on

teaching modeling for the management science stu-

dents to make them capable of describing the so-

lutions for large and complex problems as abstract

models and reasoning the models via informal/formal

techniques. In (Moisan and Rigault, 2010), the au-

thors shared their experiences on teaching UML to the

students and practitioners. Many concerns have been

addressed, including the different modes of using

UML, UML’s acceptance by the students and prac-

titioners, the case-studies to be used, and UML’s dia-

grams types and their usabilities for teaching software

modeling. In (Carrington, 1998), the author offered

a teaching methodology that focuses on the software

design and testing. Carrington promotes the applica-

tion of the Fusion methodology proposed by Hewlett

Packard for teaching software design. In (B

orstler

et al., 2012), the author focused on determining and

analysing the existing problems in teaching software

modeling and proposed some improvements on the

teaching methodologies for software modeling.

Concerning the courses on software testing, in

(Edwards, 2003), the author proposed a web appli-

cation called Web-CAT, through which students can

submit their Java programs and JUnit test-cases for

testing their programs against the test-case speciﬁca-

tions. The author also surveyed 59 students and ob-

served that Web-CAT helped students enhancing their

software testing skills. In (Jones, 2000), the author

discussed a methodology for teaching software test-

ing effectively via his SPRAE framework that deﬁnes

the principles which a student taking a software test-

ing course should learn. In (Mao, 2008), the author

proposed a course structure for software testing that

consists of four different parts: preparatory testing

practice, question-driven classroom testing, experi-

ments in lab, and enhanced training in real context.

3 PROPOSED TEACHING

METHODOLOGY

The students are assumed to have taken the software

engineering course previously and posses the ade-

ICSOFT 2019 - 14th International Conference on Software Technologies

500

Figure 1: Modeling the contractual software architectures.

quate level of knowledge on the software require-

ments speciﬁcation and architecture design in UML.

3.1 Software Architecture Modeling

In this stage, the students are aimed to be taught with

how to use contracts for the modeling of software

architectures. Given the software requirements de-

scriptions in any natural languages (e.g., English), the

students are expected to model the software architec-

tures in terms of the components and their commu-

nications ﬁrst. Here, the students are free to use any

visual modeling notations that they are comfortable

with (e.g., UML, SysML, or simple boxes and lines

drawing). After modeling the components and their

communications, the students are expected to deter-

mine for each communication link between any two

components the list of messages that the two compo-

nents exchange via the link. As depicted in Figure 1,

the message list speciﬁcation for each communication

link needs to be attached to the link to indicate which

messages are transferred via that link. Each message

can be speciﬁed in terms of a return type (if the mes-

sage includes a response to be sent back), message

name, and the list of parameters (if any). The mes-

sages in this list are each to be sent (or requested) by

one component to the other component that the com-

munication link is directed towards (i.e., component

A requests the messages from component B).

For each message that the two linked components

exchange, the expected behaviours of the components

need to be speciﬁed in a precise and understandable

way. So, the DbC approach is followed for that

purpose and each component notation is expected to

be attached with a speciﬁcation as depicted in Fig-

ure 1, which describes the component state data and

the message contracts. The component state data

are represented with a list of variables and their de-

fault (i.e., initial) values. The message contracts for

a component include a single contract speciﬁcation

for each message that the component exchange via

its communication link(s), and that contract is spec-

iﬁed with pre- and a post-conditions. Whenever the

pre-condition is satisﬁed for the message, the compo-

nent can send/receive the message, and then, the post-

condition is expected to hold. Note that pre-condition

is deﬁned over the component (pre-)state and message

parameters, while post-condition is over the compo-

nent (post-)state and the message result (if any).

3.2 Model Transformation

3.2.1 Model to Java Transformation

After modeling the contractual software architectures,

the goal is to implement the architecture models in a

way that preserves all the design decisions speciﬁed

in the architecture model. The Java programming lan-

guage is considered here, which is one of the top pop-

ular programming languages used in industries, and

most universities offer mandatory courses on Java.

1 public class com po ne nt . Name {

2 FORALL d a t a ∈ comp on ent . D a t a L i s t

3 d a t a . Type d a t a . Name = d a t a . I n i t i a l V a l u e ;

5 FORALL l i n k ∈ c omp on ent . C omm u n ic a t io n L in k L is t

6 IF l i n k IS REQUEST

7 link INTERFACE l i n k . Name ;

8 FORALL m es sa ge ∈ l i n k . M e ssa g e L is t

9 public m es sa ge . R e t urn me ss ag e . Name( m es sa ge . P a r a m e t e r L i s t ) {

10 / / p re −c o n d i t i o n

11 assert ( me ssage . pr e −c o n d i t i o n ) ;

12 / / c o m p ut a t i o n . . . . . . . . . . .

13 IF l i n k IS REQUEST

14 l i n k . Name . { m es sa ge . Name( m es sa ge . P a r a m e t er L i s t ) } ;

15 / / p os t −c o n d i t i o n

16 assert ( me ssage . p o st −c o n d i t i o n ) ;

17 }

18 }

Listing 1: Translating system components in Java.

Implementing the contractual software architec-

ture models in Java is expected to be performed via

the algorithms given in Listings 1 and 2, which are

considered for the components and communication

links respectively. As shown in Listing 1, each com-

ponent is implemented as a Java class, which consists

of an instance variable for each class data (lines 2-3)

and a class method for each message that the com-

ponent receives/sends (lines 9-17). The component

Teaching Design-by-Contract for the Modeling and Implementation of Software Systems

501

class methods consist structurally of three parts: the

pre-condition, computation, and post-condition. The

pre- and post-conditions herein are translated from the

contract speciﬁcations of the component messages.

Whenever the method is called, the pre-condition

needs to be satisﬁed ﬁrst. If so, the computation can

be performed, and the post-condition needs to be sat-

isﬁed at the end. If either the pre- or post-condition

is violated, the method-call execution fails. The pre-

and post-conditions are implemented using Java’s as-

sertion mechanism

, which can be used in Java pro-

grams for checking any condition and throwing an er-

ror if the condition is not met. Note that if a method

is translated from a request message, its computation

part in the method body delegates the call to the re-

ceiving component’s class instance via the link in-

stance variable (line 14). The link instance variable

used herein is to be instantiated with the class instance

of the link that connects the receiving and requesting

components (line 7). Thanks to the link instance vari-

able, the classes of the components that are linked are

essentially decoupled from each other, and their in-

stances may communicate only via the class instance

of the communication link, which acts as the adapter

between the linked components’ class instances.

1 FORALL l i n k ∈ co mp onent . C o mm u n i ca t i on L i n kL i s t

2 public interface l i n k . Name INTERFACE {

3 FORALL me ss ag e ∈ l i n k . M es s a g e Lis t

4 public m es sa ge . R e t ur n m es sa ge . Name ( message . P a r a m e t e r L i s t ) ;

5 }

7 public class l i n k . Name CONNECTOR implements l i n k . Name INTERFACE {

8 l i n k . R ec e iv er C om po n en t r e cei v e r C om p o n e nt ;

10 public l i n k . Name CONNECTOR ( l i n k . R ece iv e rC om p on en t r e c e i v e r ) {

11 r e ce i v e r Com p o n e nt = r e c e i v e r ;

12 }

13 FORALL me ss ag e ∈ l i n k . M es s a g e Lis t

14 public m es sa ge . R e t ur n m es sa ge . Name ( message . P a r a m e t e r L i s t ) {

15 r e ce i v e r Com p o n e nt . { me ss ag e . Name } ( ) ;

16 }

17 }

Listing 2: Translating communication links in Java.

The communication links are implemented fol-

lowing the adapter design pattern. As shown in List-

ing 2, each communication link is implemented as an

adapter class (lines 7-17). So, the link class imple-

ments an interface that comprises the deﬁnitions of

the methods which correspond to the message list for

that communication link (lines 2-5). The adaptor link

class implements the interface methods (lines 14-16)

in a way that the methods direct the calls to the re-

ceiver component class instance (i.e., adaptee) which

is received via the class constructor (lines 10-11).

Java assertion statement: https://docs.oracle.com/

javase/7/docs/technotes/guides/language/assert.html

1 public class com po ne nt . Name {

2 FORALL d a t a ∈ comp on ent . D a t a L i s t

3 d a t a . Type d a t a . Name = d a t a . I n i t i a l V a l u e ;

5 FORALL l i n k ∈ c omp on ent . C omm u n ic a t io n L in k L is t

6 IF l i n k IS REQUEST

7 link INTERFACE l i n k . Name ;

8 FORALL m es sa ge ∈ l i n k . M e ssa g e L is t

9 / ∗ @public normal behavior

10 @requires : m es sa ge . p re −c o n d i t i o n

11 @ensures : mess ag e . p o st −c o n d i t i o n

12 @ ∗ /

13 public m es sa ge . R e t urn me ss ag e . Name( m es sa ge . P a r a m e t e r L i s t ) {

14 IF l i n k IS REQUEST

15 l i n k . Name . { m es sa ge . Name( m es sa ge . P a r a m e t er L i s t ) } ;

16 }

17 }

Listing 3: Translating system components in JML.

3.2.2 Model to JML Transformation

Maintaining consistencies between the contractual

speciﬁcation and the Java implementation is also an

issue and needs to be addressed for reliable software

systems. Note that any changes made on the contrac-

tual design may be neglected for the Java implemen-

tation; and this will make the design and implementa-

tion inconsistent. To minimise the gap between model

and implementation, the students are encouraged to

learn and use JML, which is one of the top-used soft-

ware modeling languages in industry (Ozkaya, 2018)

and allows for combining the contractual software

model with the Java implementation. In JML, the Java

class methods are annotated with the contract spec-

iﬁcations that are attached at the top of the method

declarations. Thanks to the veriﬁer tools that support

JML (e.g., KeY (Ahrendt et al., 2016) and OpenJML

(Cok, 2011)), the Java programs can be formally ver-

iﬁed for the contractual JML speciﬁcations.

Since JML is essentially the extension of the Java

language, the same rules discussed in Section 3.2.1

can be used by students to model their software sys-

tems in JML. That is, a separate class is generated

for each component and connector link and each class

has the same structure as given in the Java trans-

formation algorithms in Listings 1 and2. However,

while the Java translations use Java’s assert state-

ments for checking contracts, the JML translation in-

cludes the contract annotations attached to the class

methods. Listing 3 gives the modiﬁed algorithm for

transforming the component speciﬁcations in JML.

JML contracts are speciﬁed as comments (/*@ ...

@*/) that are attached to the head of the class meth-

ods. JML essentially offers an expressive notation set

for modeling contracts

, but for simplicity, only the

basic JML constructs are considered. The JML con-

structs considered herein are the normal behaviour

construct for describing the normal case for a method

behaviour that is supposed to end with a successful

JML reference manual: http://www.eecs.ucf.edu/ leav-

ens/JML/jmlrefman/jmlrefman toc.html

ICSOFT 2019 - 14th International Conference on Software Technologies

502

termination, the requires pre-condition, ensures post-

condition, and \result construct for representing the

result to be returned after the method-call.

4 A CASE STUDY - GAS STATION

SYSTEM

The author considers the gas station system (Nau-

movich et al., 1997) as the case-study for demonstrat-

ing the use of the teaching methodology introduced

in Section 3. Given its appropriateness for the DbC-

based software modeling and simplicity, the gas sta-

tion system may further be used in the classrooms as

the medium for making the students understand the

teaching methodology. Indeed, the students can ini-

tially be provided with the informal requirements of

the gas station system (in textual, plain English for-

mat) and expected to use DbC for modeling and im-

plementing the gas station architecture in the way in-

troduced in the rest of this section that consider the

translation algorithms discussed in Section 3.

4.1 Software Architecture Modeling

Given the textual description of the gas station sys-

tem, the students may specify the the system compo-

nents and their communication links as the author did

in Figure 2. So, the gas station system comprises the

customer, cashier, and pump components. The cus-

tomer interacts with the cashier to make the gas pay-

ment. Upon receiving the payments, the cashier asks

the pump to release gas for the customers. Then, the

customer may receive the gas paid from the pump.

The next step is to extract the behaviour descrip-

tions and document them contractually as given in

Figure 2. So, the customer’s pay message contract

states that the pay message may only be sent if the

requestMade data of the customer component is false

and the amount parameter is in equal to 1. After the

customer requests the pay message, the component

state must be updated so that the requestMade data

is set to true and the chosenAmount data is set to the

amount parameter. Customer’s pump request is per-

formed if the requestMade data is true (i.e., the cus-

tomer already made the pay request). Then, after the

pump message is requested, if the result to be returned

is equal to the chosenAmount data, the requestMade

data can be set back to false again so as to perform

new payment requests. Note that the pump message

is speciﬁed with a return type (i.e., int) in Figure 2.

The cashier component receives and accepts the

pay message only if the component’s paymentAmount

data is 0 (i.e., the pre-condition). After the pay

message is accepted and the necessary computations

are performed, the paymentAmount data must be set

to the amount parameter of the message (i.e., post-

condition). The cashier component may request the

releasePump message if the paymentAmount data is

not equal to 0 and the amount parameter is equal to the

paymentAmount data (i.e., the pre-condition). That

is, before the releasePump message is requested, the

pay message request needs to be received ﬁrst and the

amount of the gas to be released must be equal to the

amount paid for. After the releasePump message is

requested, the paymentAmount data must be set to 0

(i.e., post-condition). Note that this allows for receiv-

ing the pay message again.

Lastly, the pump component receives and ac-

cepts the releasePump message if the component’s

pumpReleased data is false (i.e., pre-condition).

Then, after the message is received, the pumpRe-

leased data must be set to true and the paymentA-

mount data set to the amount parameter. The pump

component receives and accepts the pump message

if the pumpReleased data is true and the paymentA-

mount data is not 0 (i.e., the releasePump message

received ﬁrst). Then, after the pump message is re-

ceived, the pumpReleased data must be set to false

and the result to be returned back to the customer must

be set to paymentAmount data.

4.2 Model Transformation

After documenting the contractual gas station archi-

tecture as given in Figure 2, the students may use the

algorithm rules discussed in Section 3.2.1 to imple-

ment their architecture speciﬁcation in Java in a way

that the behavioural design decisions for the com-

ponents are all preserved. The students may further

modify the Java implementation in accordance with

the rules discussed in Section 3.2.2 so as to obtain

the JML model for the gas station. Figure 3 depicts

how the author implemented the customer compo-

nent speciﬁcation in Java and transform the Java code

in JML. Also, Figure 4 shows how the author im-

plemented the communication links speciﬁed for the

customer and cashier components in Java, which es-

sentially act as the adapter between the components.

Indeed, in Figure 3, the class instance for customer

uses the link instance for making a method-call to the

class instance for cashier. The author’s full Java code

and JML model for the entire gas station architecture

can be found in the web-site of the software testing

course

, which has been used for evaluating the teach-

ing methodology as discussed in the next section.

Software testing course web-site: https://sites.

google.com/site/drmertozkaya/softwaretest

Teaching Design-by-Contract for the Modeling and Implementation of Software Systems

503

Figure 2: The contractual speciﬁcation of the gas station system.

Figure 3: Transforming the customer component speciﬁcation in Java and JML.

Figure 4: Transforming the link speciﬁcation between customer and cashier components in Java and JML.

5 PRELIMINARY EVALUATION

The DbC-based teaching methodology discussed in

this paper has been used in the software testing course

that are offered by the author as a technical elec-

tive course at Yeditepe University, Istanbul for the

3rd and 4th (ﬁnal) year computer science (CS) un-

ICSOFT 2019 - 14th International Conference on Software Technologies

504

Table 1: The course syllabus for teaching how to design and implement reliable software systems.

Week Activity Total Hours Teaching Method

1 Introduction to Defensive Programming and DbC 1 Lecture Slides

Jazequel and Meyer’s article entitled ”Design by Contract: The Lessons of Ariane”

equel and Meyer, 1997)

1 Reading and interactive discussion

2 Introduction to Modeling with DbC 1 Lecture Slides

2 Modeling with DbC via the Gas Station System 2 Guided Class Practice

1 Introduction to Java’s Assertion Mechanism 1 Lecture Slides

3 Introduction to Implementing DbC-based Models in Java with Assertions 2 Lecture Slides

3, 4 Implementing the Gas Station System in Java 2 Guided Class Practice

4, 5 Introduction to JML 3 Lecture Slides

5 Modeling the Gas Station System in JML 2 Guided Class Practice

dergraduate students. Note that the software engi-

neering course is a pre-requisite for the software test-

ing course. The software testing course has been en-

rolled by 19 Yeditepe CS students in Autumn 2018.

The course syllabus has been enriched with the 5-

weeks long materials shown in Table 1, which has

been taught in 15 hours in total (i.e., 3 hours per

week)

. So, the goal here is to introduce students the

important concepts of model-driven software devel-

opment (e.g., modeling software architectures, DbC,

and model transformation) and make them gain some

practical experience on using DbC for the modeling

and implementing software systems.

As indicated in Section 3, the defensive program-

ming and DbC topics have been introduced initially.

To attract the students’ interest further, Jazequel et

al.’s article (J

equel and Meyer, 1997) on the DbC

approach has been studied and discussed in the class-

room in an interactive way, which aid in illustrating

the importance of DbC via the Ariane 5 space shut-

tle explosion. Following that, a 1-hour introductory

session has been conducted on the DbC-based archi-

tecture modeling with the goal of enhancing the stu-

dents’ capability of using contracts for the speciﬁca-

tions of architectural components as discussed in Sec-

tion 4.1. Then, the students have been involved in a

guided class exercise for the contractual modeling of

the gas station system architecture. Note here that the

students have been initially given the informal, half-

page description of the gas station system require-

ments in English and free to use any modeling tools

(or draw on a paper). In the next step, another 1-hour

introductory session has been conducted on the Java

assertion mechanism so as to teach the use of asser-

tions in Java. This has been followed with a 2-hours

session for teaching how to implement the contractual

software models in Java using Java’s assertion mecha-

nism in accordance with the algorithm rules discussed

in Section 3.2.1. Then, the students have been ex-

pected to implement their gas station models in Java

with its assertion mechanism. Lastly, JML’s notation

set has been introduced to the students, and the stu-

dents have been taught with how to transform any

Java program with assertions into a JML model with

contract annotations that needs to satisfy the transla-

tion rules discussed in Section 3.2.2. Then, in another

2-hours practice session, the students have been asked

to combine their gas station architecture model and its

Java implementation into a JML model this time. Af-

ter modeling with JML, the students used the Open-

JML tool (Cok, 2011)

to verify their JML models

for the gas station example and check exhaustively

whether their Java program satisﬁes their contractual

speciﬁcations. Note that OpenJML also provides a

free online veriﬁcation tool that saves the students

from having to download and install any applications.

During the course, the students’ feedback have

been received regularly via the Q&A sessions that

have taken place in the last 15 minutes of each ses-

sion. Also, at the end of the course, a quick survey

has been conducted among the students so as to un-

derstand their thoughts on the taught topics. So ap-

parently, none of the students have ever heard about

the important concepts taught in this course, includ-

ing defensive programming, DbC, and model trans-

formation. Also, the students stated that they have

not considered so far any means of enhancing the re-

liability of the software systems. The students’ under-

standing on software reliability is basically restricted

with testing software implementation for a set of ex-

pected inputs, and other relevant topics such as model

checking, verifying software implementation for the

model have not been studied before. While the stu-

dents are all familiar with Java, none of them ever

used Java’s assertion mechanisms before. The stu-

dents stated that they viewed a software module as a

unit of computation only without considering to check

for any pre- or post-conditions. JML is also com-

pletely new to the students. As the students com-

pleted each lecture session given in Table 1, they have

been observed to show a great interest to the contract-

based modeling and the ability of JML in combin-

ing the contractual modeling with implementation for

promoting the reliable software systems that are guar-

anteed to satisfy the design decisions. The students

got highly impressed with how easy it is to model

software behaviours in terms of contracts that simply

require specifying conditional statements without the

OpenJML’s web-site: https://www.openjml.org/

Teaching Design-by-Contract for the Modeling and Implementation of Software Systems

505

need to learn and use any complex techniques. JML’s

tool support for the exhaustive checking of the Java

code for the contract speciﬁcations via formal meth-

ods has also been so interesting to the students. In-

deed, the capability of checking all possible execution

paths is a great facility to the students. However, some

students are quite concerned that JML’s notation set is

more than just simple pre- and post-conditions and re-

quires some learning curve. The students were keen to

visually specify the JML models and verify, and im-

plement the models in Java automatically, rather than

writing textual speciﬁcations as is the case with JML.

Concerning the students’ experiences observed,

most of the students suffered from obtaining a con-

tractual software architecture model from the require-

ments statement of the gas station system. While the

students were all able to specify the structural aspect

of gas station, they found it quite challenging to ﬁg-

ure out the component behaviours. Even if the stu-

dents managed to determine the messages that the

components exchange, they hardly determined how

the messages impact on the component state. So,

the author provided further clariﬁcations on the re-

quirements and helped the students grasp some im-

plicit details. Moreover, most of the students were

not so good at translating the software architectures

into software implementation manually in accordance

with the rules given. This was essentially due to the

lack of knowledge on the adapter design pattern that

the translation rules are based on.

6 CONCLUSION

In this paper, a novel teaching methodology has been

proposed for the undergraduate students to learn how

to use DbC for the modeling and implementation of

reliable software systems. The teaching methodol-

ogy comprises three steps to be performed. The stu-

dents are initially taught how to specify the contrac-

tual behaviours of the components that compose the

software architectures. That is, each component no-

tation is enriched with the contractual behaviours of

the messages that the component exchanges. In the

second step, the students are taught how to imple-

ment their contractual software architectures in Java

in accordance with a simple algorithm to be followed

that uses the Java assertions for checking the message

contracts. To avoid any potential consistency issues

between the software model and implementation, the

methodology further proposes in its last step the al-

gorithm for combining the contractual modeling of a

software with its Java implementation via the use of

the JML language, which is also supported with many

veriﬁer tools that can automatically prove the correct-

ness of the Java programs for the contractual models.

To evaluate the DbC-based teaching methodology,

the author extended the syllabus of his undergraduate

software testing course at Yeditepe University and the

students have been taught with the necessary materi-

als along with a guided class exercise on the gas sta-

tion example in autumn 2018. According to the stu-

dents’ feedback received, the topics such as defensive

programming, DbC, and JML seem to be completely

new to them and the students got really surprised on

how easy it is to model the behaviours of software

modules contractually. The students also showed a

great level of interest towards JML and its capabili-

ties for verifying the Java implementation against the

contractual models. However, the students have been

observed to face some difﬁculties in extracting the

behavioural design decisions from the requirements

statement and also expressed their desire on using

JML via some visual notation set.

While the teaching methodology introduced in the

paper got so many positive feedback, the lack of lan-

guage and tool support highly limit its applicabil-

ity. So, we have currently been developing a soft-

ware modeling language and its toolset for teach-

ing students the important concepts of model-driven

software development such as the software architec-

ture modeling, DbC, multiple-viewpoints modeling,

model analysis, and code generation. The new lan-

guage will allow the students to use a simple boxes-

and-lines based visual notation set for modeling soft-

ware architectures from multiple viewpoints, which

are the use-case, logical, behaviour, and physical

viewpoints. Note that the behaviour viewpoint is in-

spired from the contractual behaviour modeling dis-

cussed in this paper. The students will also be able

to use the toolset for performing many operations

on their architecture models. These include check-

ing the consistency between different viewpoint mod-

els, checking the model completeness, transforming

the models into Java and JML in accordance with the

algorithms discussed in the paper, and transforming

the models into any formalisms for formal veriﬁca-

tion. The new toolset is expected to be evaluated

via the software engineering, software architecture,

and software testing undergraduate courses offered at

Yeditepe University.

REFERENCES

Ahrendt, W., Beckert, B., Bubel, R., H

ahnle, R., Schmitt,

P. H., and Ulbrich, M., editors (2016). Deductive Soft-

ware Veriﬁcation - The KeY Book - From Theory to

ICSOFT 2019 - 14th International Conference on Software Technologies

506

Practice, volume 10001 of Lecture Notes in Computer

Science. Springer.

Alfonso, M. I. and Botia, A. (2005). An iterative and agile

process model for teaching software engineering. In

18th Conference on Software Engineering Education

Training (CSEET’05), pages 9–16.

Barnett, M., F

ahndrich, M., Leino, K. R. M., M

uller, P.,

Schulte, W., and Venter, H. (2011). Speciﬁcation and

veriﬁcation: The spec# experience. Commun. ACM,

54(6):81–91.

orstler, J., Kuzniarz, L., Alphonce, C., Sanders, W. B., and

Smialek, M. (2012). Teaching software modeling in

computing curricula. In Proceedings of the Final Re-

ports on Innovation and Technology in Computer Sci-

ence Education 2012 Working Groups, ITiCSE-WGR

’12, pages 39–50, New York, NY, USA. ACM.

Carrington, D. (1998). Teaching software design and test-

ing. In FIE ’98. 28th Annual Frontiers in Educa-

tion Conference. Moving from ’Teacher-Centered’ to

’Learner-Centered’ Education. Conference Proceed-

ings (Cat. No.98CH36214), volume 2, pages 547–550

vol.2.

Claypool, K. and Claypool, M. (2005). Teaching soft-

ware engineering through game design. SIGCSE Bull.,

37(3):123–127.

Cok, D. R. (2011). Openjml: Jml for java 7 by extending

openjdk. In Bobaru, M., Havelund, K., Holzmann,

G. J., and Joshi, R., editors, NASA Formal Methods,

pages 472–479, Berlin, Heidelberg. Springer Berlin

Heidelberg.

Edwards, S. H. (2003). Teaching software testing: Au-

tomatic grading meets test-ﬁrst coding. In Compan-

ion of the 18th Annual ACM SIGPLAN Conference on

Object-oriented Programming, Systems, Languages,

and Applications, OOPSLA ’03, pages 318–319, New

York, NY, USA. ACM.

Gnatz, M., Kof, L., Prilmeier, F., and Seifert, T. (2003).

A practical approach of teaching software engineer-

ing. In Proceedings of the 16th Conference on Soft-

ware Engineering Education and Training, CSEET

’03, pages 120–, Washington, DC, USA. IEEE Com-

puter Society.

Hoare, C. A. R. (1969). An axiomatic basis for computer

programming. Commun. ACM, 12(10):576–580.

equel, J.-M. and Meyer, B. (1997). Design by contract:

The lessons of ariane. Computer, 30(1):129–130.

Jones, E. L. (2000). Software testing in the computer sci-

ence curriculum – a holistic approach. In Proceedings

of the Australasian Conference on Computing Educa-

tion, ACSE ’00, pages 153–157, New York, NY, USA.

ACM.

Leavens, G. T., Poll, E., Clifton, C., Cheon, Y., Ruby, C.,

Cok, D., Mller, P., Kiniry, J., and Chalin, P. (2008).

JML Reference Manual. Iowa State University, 1.220

edition.

LeJeune, N. F. (2006). Teaching software engineering prac-

tices with extreme programming. J. Comput. Sci.

Coll., 21(3):107–117.

Mao, C. (2008). Towards a question-driven teaching

method for software testing course. In 2008 Interna-

tional Conference on Computer Science and Software

Engineering, volume 5, pages 645–648.

Meyer, B. (1992). Applying “Design by Contract”. IEEE

Computer, 25(10):40–51.

Moisan, S. and Rigault, J.-P. (2010). Teaching object-

oriented modeling and uml to various audiences. In

Ghosh, S., editor, Models in Software Engineering,

pages 40–54, Berlin, Heidelberg. Springer Berlin Hei-

delberg.

Naumovich, G., Avrunin, G. S., Clarke, L. A., and Oster-

weil, L. J. (1997). Applying static analysis to software

architectures. In Jazayeri, M. and Schauer, H., editors,

ESEC / SIGSOFT FSE, volume 1301 of Lecture Notes

in Computer Science, pages 77–93. Springer.

Ozkaya, M. (2018). Do the informal & formal software

modeling notations satisfy practitioners for software

architecture modeling? Information & Software Tech-

nology, 95:15–33.

Ozkaya, M. and Kloukinas, C. (2014). Design-by-

contract for reusable components and realizable ar-

chitectures. In Seinturier, L., de Almeida, E. S.,

and Carlson, J., editors, CBSE’14, Proceedings of

the 17th International ACM SIGSOFT Symposium

on Component-Based Software Engineering (part of

CompArch 2014), Marcq-en-Baroeul, Lille, France,

June 30 - July 4, 2014, pages 129–138. ACM.

Powell, S. G. (2001). Teaching modeling in manage-

ment science. INFORMS Transactions on Education,

1(2):62–67.

Rademaker, A., de O. Braga, C., and Sztajnberg, A. (2005).

A rewriting semantics for a software architecture de-

scription language. Electr. Notes Theor. Comput. Sci.,

130:345–377.

Reussner, R., Poernomo, I., and Schmidt, H. (2003). Rea-

soning about Software Architectures with Contrac-

tually Speciﬁed Components. In Cechich, A., Piat-

tini, M., and Vallecillo, A., editors, Component-Based

Software Quality, volume 2693 of Lecture Notes in

Computer Science, page 287?325. Springer Berlin

Heidelberg.

Severance, C. (2012). Bertrand meyer: Software engineer-

ing and the eiffel programming language. Computer,

45(9):6–8.

Starrett, C. (2007). Teaching uml modeling before program-

ming at the high school level. In Seventh IEEE Inter-

national Conference on Advanced Learning Technolo-

gies (ICALT 2007), pages 713–714.

Tamai, T. (2005). How to teach software modeling. In Pro-

ceedings. 27th International Conference on Software

Engineering, 2005. ICSE 2005., pages 609–610.

Teaching Design-by-Contract for the Modeling and Implementation of Software Systems

507