A LARGE AMOUNT OF FINAL PROJECTS EFFECTIVELY

PROCESSED WITH MINIMAL SOFWARE REQUIREMENTS

Open Source and Platform Independent Solution: A Case Study

Michal Valenta

Czech Technical University, Faculty of Electrical Engineering, Czech Republic

Keywords:

Final project Grading, XML, XSLT, HTML.

Abstract:

In this paper, we present a case study based on our two-years experience with a processing of a large amount

of ﬁnal projects (1200 students) in a basic course on database systems (Databases 101). Each student is

required to present his/her own project documentation with a relatively well-deﬁned structure and content.

The present paper offers a solution to the following bias: each student has his/her own preferred/disfavored

editor and, at the same time, the teacher needs to see all the ﬁnal projects in a unitary format to make the

results controlable. Furthermore, we address the issue of automated (or semi-automated) processing of some

parts of the controling process. Importantly, the whole process involves exclusively standardized technologies

implemented in many (also open-source) tools, XML and XSLT standardized by W3C in particular.

1 INTRODUCTION AND

MOTIVATIONS

There are many sophisticated tools for teaching sup-

port, however, these tools often offer only proprietary

solutions (moreover, usually to problems one is not

concerned with at the moment). In this paper, we

show how to use very common and basic tools to

achieve a relatively easy control (and feedback op-

tions) for the teacher on one hand and a relatively

non-constrained requirement on the students. Hence,

a win-win solution with minimal technology require-

ments.

The problem we deal with is this: there is about

600 students per semester at the basic Database sys-

tems course (Databases 101). Each of the students has

to present a ﬁnal project. This project has a form of

a paper that has to be processed and controlled by a

teacher. Hence, the challenge is to make it both pos-

sible for the teacher to control the papers relatively

easily on one hand and, on the other, not to impose a

system on a student (in particular a system he or she

is not used to work with).

There is a plenty of systems available for such

purposes (we have some experience with moodle on

CTU).

Starting with open-source solutions, we are usually

faced with a poor documentation. Moreover, we have

to invest a lot of effort to install (and maintain) these

tools. Adding furthermore long and expensive train-

ing period both for the teacher and the student, we

want something simpler for our purposes.

Additionally, it is very often the case that these

systems are equipped with too many functions that

are usually unnecessary for both the teacher and the

student.

So, it seems that we want to balance the over-

whelming power of these systems with our real needs

of efﬁcient and relatively easy control of the ﬁnal

projects.

In this paper, then, we present the initial problem

(a large amount of ﬁnal projects that need to be con-

trolled; the requirements will be deﬁned below) and

our solution to this problem based on the following

technologies - http, webdav, xml and xslt. The solu-

tion has gone through a two year cycle, hence, about

1200 students participated in the course Databases

101.

The main theses of this case study are:

• basic course of DBS (Databases 101),

• several hundreds of students per semester,

• individual projects,

• certain requirements for both the structure and the

ﬁnal format,

• crucial impossibility to impose one or few editors

on the students,

236

Valenta M. (2009).

A LARGE AMOUNT OF FINAL PROJECTS EFFECTIVELY PROCESSED WITH MINIMAL SOFWARE REQUIREMENTS - Open Source and Platform

Independent Solution: A Case Study.

In Proceedings of the First International Conference on Computer Supported Education, pages 235-240

DOI: 10.5220/0001972702350240

 SciTePress

• further advantage: possible automated processing

of (at least) some parts of the ﬁnal projects.

The rest of the paper is organized as follows: ﬁrsts, we

give a detailed description of the requirements on the

ﬁnal projects from DBS (Databases 101) in the sec-

tion 2. Advantages of the implementation of our so-

lution with respect to the technologies used and their

compatibility as well as students’ point of view is pre-

sented in the section 3. In the section 4, we present

our experience after two semesters

. We consider

two groups of students here – students familiar with

XML/XSLT technologies vs. those without such ex-

perience. To conclude, in the section 5, we summarize

our ﬁndings with respect to the above speciﬁed state-

ments. Also, we shortly discuss the future work and

potential extensions here.

2 FINAL PROJECT

REQUIREMENTS

Our aim is to provide a structure for the students’ ﬁ-

nal projects. This structure must be ﬂexible enough

to reﬂect the needs of the descriptive parts of the doc-

ument. On the other hand, it must be rather strict,

as it deﬁnes the names and the order of the required

parts of the document. The requirements for the ﬁ-

nal project structure are not so strict to allow fully

automated processing as it is usual in programming

courses, see (Cheang et al., 2003) and (Helmick,

2007) for example.

XML (Extended Markup Language) seems to be

an ideal format for these purposes. So, the ﬁnal

project is ought to be presented as an XML docu-

ment. There are some basic rules on syntax of a

XML document. A document which satisﬁes such

rules is called well-formed. See W3C pages for de-

tail (http://www.w3c.org).

However, a well-formed XML document still does

not meet our expectation on the ﬁnal project struc-

ture. We need to strictly specify the names of indi-

vidual ﬁnal project parts (elements in XML terminol-

ogy), the order of these elements, and their cardinality

(the number of their occurrences in certain context).

For example, an element description which

represents one part of the ﬁnal project document, con-

sists of exactly one element title followed by at

least one (but potentially more) paragraphs. Each

paragraph consists of an element para optionally fol-

lowed by an element comment. In DTD formalism

(see bellow), this requirement looks as follows:

description (title, (para, comment?)+)

Databases 101 runs only in the Fall semester.

For these purposes, a document type description can

be speciﬁed. A document is then checked against this

structural description. If it satisﬁes all the require-

ments on the document type description, it is marked

as valid.

There are three notations/languages used for a

document type deﬁnition – DTD, XML Scheme, and

RelaxNG. We choose DTD, since it is the simplest

one, yet, it is powerful enough for our purposes.

Each DTD speciﬁcation can be automatically trans-

lated into XML Scheme as well as RelaxNG speciﬁ-

cation. These facts, in turn, are important for XML

document editing. Some editors do not support DTD,

but require XML Scheme, for example.

A complete DTD speciﬁcation for a DBS ﬁnal

project is included in Appendix A.

2.1 Final Project Parts

Let us shortly describe the main parts of the ﬁnal

project. We will refer to them in chapter 3.

2.1.1 Domain Description

First, students are required to specify their own

database for an implementation. They have to de-

scribe the context they are going to model on a con-

ceptual level and, subsequently, they have to imple-

ment it in SQL server

. This part consists of mini-

mally one, typically several paragraphs.

2.1.2 Conceptual Model

As a second step, students formalize their domain in

ER (Entity Relationship) notation. They use a special

tool for ER modeling in this stage of the work. They

are required to include a ﬁgure of their ER model and

an URL link to the source code of this model into their

ﬁnal project documentation.

This part also requires at least one additional para-

graph, in which the students discuss the potential

problems of loops that might arise in their model and

they also formulate additional integrity constraints

(such that can’t be described in ER notation).

2.1.3 Relational Database Implementation

This stage of the ﬁnal project consists of several indi-

vidual parts. We’ll describe each of them in the fol-

lowing paragraphs.

As a rule, Oracle is used for all the courses.

A LARGE AMOUNT OF FINAL PROJECTS EFFECTIVELY PROCESSED WITH MINIMAL SOFWARE

REQUIREMENTS - Open Source and Platform Independent Solution: A Case Study

237

SQL Script for Database Creation. It can be cre-

ated automatically from the tool used for the ER

model creation. Students can edit and comment on

this script. The SQL script is then included as a URL

link into the ﬁnal project documentation.

SQL Script for Database Initialization. Students

are required to create a set of INSERT statements in

order to ﬁll their database. It is necessary for further

SQL statements development. It is included as a URL

link in the ﬁnal project documentation.

SQL Statements. Students have to design at least

25 SQL statements of various complexity over their

database. Various types of SQL statements are de-

scribed in a table, which is then included in this part

of the ﬁnal project documentation. Students have to

cover each column of the table by at least one SQL

statement. Each SQL statement consists of a descrip-

tion, SQL code and potentially a formulation of a

query in relational algebra notation (students have to

provide a relational algebra notation for at least 10

queries).

SQL Script with SQL Statements. In order to con-

trol for a correctness of their SQL code, students are

required to attach a sql script consisting of only SQL

statements. This script can be created automatically

from the ﬁnal project documentation using another

XSLT transformation; see section 3 and ﬁgure 1 for

details. The script is included as a URL link in the

ﬁnal project documentation.

SQL Statements Report. In order to show that

their SQL statements really work, students have to in-

clude a report with SQL server responses to their SQL

statements. Again, this document can be created au-

tomatically running previous sql script in SQL server.

See ﬁgure 1 for details. As before, this report is in-

cluded as a URL link in the ﬁnal project documenta-

tion.

2.1.4 Conclusion

This section serves exclusively for the students’ re-

view of their experience. It thus has at least one para-

graph in the Final project documentation.

2.2 Comments

We decided to add (optional) comments to most parts

of the ﬁnal project docementation structure. It is

meant as a place for discussion or comments on a par-

ticular solution both for the students and the teacher.

It is implemented using a button with java script func-

tionality which allows to shows or hide all comments

in the ﬁnal work in its web presentation. See chapter

3 for details.

3 IMPLEMENTATION

3.1 Technical Description

Figure 1 provides a brief description of the technolo-

gies used in the ﬁnal project and of the ﬁnal project

document processing. Let us describe the processes

in detail here. We will refer to the labels of arrows in

ﬁgure during our explanation.

structure description

DTD / XML Scheme

/ Relax NG

XML File

ﬁnal

project

XSLT 1

to html

XSLT 2

to SQL

WWW browser

with XSLT processor

Mozilla Firefox, MS IE, ...

arbitrary (XML) editor

emacs, notepad,

XML Mind, XML Spy, ...

XSLT

Procesor

SQL

script

SQL

server

report

3. 4.

Figure 1: Tools envolved in the ﬁnal work processing.

1. Final project document points to a related DTD

in a meta-element <!DOCTYPE>. Hence, each tool

which is used for a ﬁnal project document can ac-

cess and use a DTD speciﬁcation to validate the

document.

2. In another meta-element – <?xml-stylesheet>,

the ﬁnal project document points to a XSLT1

transformation program (by URL). It transforms

the ﬁnal project document into html. Visual for-

matting of output html document is done through

CSS (Cascade Style Sheet) which is included in

the head of the output html document by standard

html tag <link>.

3. Editing of the ﬁnal project document. This is the

main task in the whole process. A document can

be edited either by a student (most often), po-

tentially by a teacher (especially comment ele-

ments). Editing can be done either locally on stu-

dents’/teachers’ PC, or directly on a server (if it is

supported by the access protocol). Practically, we

are using WebDAV protocol which allows remote

ﬁle editing. Related DTD of the document can be

used by the editor (dotted arrow), but a document

can be (and it often is) edited by an arbitrary (non-

XML specialized) editor.

CSEDU 2009 - International Conference on Computer Supported Education

238

4. This arrows represents the main beneﬁt of our so-

lutions. The ﬁnal document is placed on a web

server into a folder accessible through http pro-

tocol. If a user uses WWW browser with XSLT

processor (actually, this feature is implemented in

many browsers: Mozilla, Firefox, Opera, Safari,

Microsoft IE), then the XML document is auto-

matically transformed via related XSLT (see label

2. above) and displayed as html page. Unfortu-

nately, the relation to XSLT transformation inside

XML document (although it is standardized!) is

not implemented in a standard way (always – i.e.

in MS IE). Hence, if one sustains on using MS IE

for his/her ﬁnal project, it is necessary to (slightly)

modify XSLT 1.

5. This processing is optional. Another XSLT tem-

plate (XSLT 2 in ﬁgure) can be applied to the ﬁnal

project document. It extract only a part related to

SQL statements and it creates a SQL srcipt which

can be directly run in a SQL server.

6. Actually, our XSLT 2 transformation is built for

optimal use with Oracle SQL server. It includes

settings for sqlplus command tool and in this way

it generates a html report with responses to SQL

statements. It is also a required part of the ﬁnal

project (see 2 for details).

3.2 Users’ Point of View

In this subsection, we’re going to describe the whole

process of the creation of the ﬁnal project from the

point of view of a user – i.e. a student as a creator and

a teacher as a reviewer. We’ll do it in a way of “use

cases”.

Suppose now that the ﬁnal project ﬁles are placed

on a server, which provides http and WebDAV (possi-

bly ftp or scp) access to ﬁles. Both the student and the

teacher know URL (Uniﬁed Resource Locator) which

points to a particular ﬁnal project documentation.

3.2.1 Student

Edit Final Project. The student can edit the ﬁnal

project document using an arbitrary editor. As before,

it can be done locally by transferring the document,

editing it locally and then posting it back to the server.

And again, it can be done by a special feature of a

remote editing as well.

View Final Project. In a web browser with XSLT

support (Firefox is recommended) type URL of XML

document. It is displayed with a proper formatting.

Use embedded push button to hide/show comments

in the document.

Deliver Required File to the Server. An arbitrary

ﬁle can be posted to the project folder on the server

and then linked from the ﬁnal project document via

URL. The delivery is done via server supported tech-

nology (WebDAV in our case). An arbitrary tool can

be used. WebDAV protocol is also supported in tools

like Konqerror in Linux KDE environment or Ex-

plorer in MS Windows.

Deliver Figure to the Server. A ﬁgure of concep-

tual model is required as a part of the ﬁnal project. It

can be delivered in the same way as another ﬁles. See

the paragraph above.

Create Script with SQL Statements. Use any xslt

procesor and apply XSLT2 template to the ﬁnal

project document. There are free as well as payed

xslt prcoessors (Xerces, xsltproc, or xalan for exam-

ple). Moreover, XSLT2 template can be downloaded

from the project server.

Run SQL Script and Obtain Report. In sqplus

run sqlscript which is the output of XSLT2 transfor-

mation. It creates the report automatically.

3.2.2 Teacher

View Final Project. In a web browser with XSLT

support (Firefox is recommended) type URL of XML

document. It is displayed with a proper formatting.

Use embedded push button to hide/show comments

in the document.

Comment on a Part of the Final Project. Using

an arbitrary editor, edit a chosen comment element (it

can also be added according to DTD speciﬁcation).

It can be done locally by transferring the document,

editing it locally and then posting it back to the server,

or, as before, by using a special feature of remote edit-

ing.

3.2.3 Recommended Editor

Let us note that any kind of an editor (either XML or

non-XML one) can be used, but there is also a recom-

mended (i.e. supported) one.

We choose XMLMind editor. It is implemented in java

language, so it is a platform independent. A commu-

nity edition is free of charge. On the other hand, a

payed version has the posibility to edit ﬁles directly

on a remote server via WebDAV protocol (which has

proven as beneﬁcial in our case).

The editor works in WYSIWYG (What You See Is

A LARGE AMOUNT OF FINAL PROJECTS EFFECTIVELY PROCESSED WITH MINIMAL SOFWARE

REQUIREMENTS - Open Source and Platform Independent Solution: A Case Study

239

What You Get) mode. We spent some effort to pro-

vide formatting identical to the ﬁnal presentation via

html (see ﬁgure 1 and description of label 4., as dis-

cussed in chapter 3).

A support of our ﬁnal project document process-

ing is implemented as a standard XMLMind plugin.

So, its installation and conﬁguration is trivial and

user-friendly.

4 OUR EXPERIENCE

The students in the DBS course (Databases 101) are

not a homogenous group of students. In particular,

there are students who have already passed a course

on XML Technologies (hence, they are familiar with

XSLT transformations). On the other hand, there are

students without a prior knowledge of the XML tech-

nologies. Nevertheless, it turned out that the prior

knowledge of the XML technologies is not a special

advantage, as we might have suspected from the be-

ginning, for the Databases 101 course. That is, all the

students are capable to successfully submit their ﬁnal

projects and, moreover, the students found the process

described here very helpful and useful. In particular,

they are thrilled by the fact that the rigid structure of

the documentation (via its validity) contains all the

required parts and they do not have to concentrate on

the formatting side of the ﬁnal project. Interestingly,

vast majority of the students used the simplest possi-

ble editor (Notepad) for editing the XML. However,

it seems that the possibility to write comments (as de-

scribed in chapter 2) is not widely used neither by the

students, nor by the teacher.

5 CONCLUSIONS AND FUTURE

WORK

Two years after having implemented the proposed

solution we can summarize that the project was very

successful and useful not only for the students, but –

importantly – also for the teacher responsible for the

control of the ﬁnal projects. The proposed solution

meets the requirements we diagnosed in the ﬁrst

chapter: it is simple, it is not dependent on a propri-

etary solution, it is not time consuming, it is based on

an open source and standardized technologies.

In the future, we would like to extend the auto-

matic SQL control of the ﬁnal projects. Once a script

with SQL questions is automated, it will be possible

to run it on SQL server and automatically analyze the

report.

However, the possibility of further automated control

of such ﬁnal projects is directly proportional on the

structure and requirements of the ﬁnal project. Still,

leaving aside these potential extension, we found

the proposed way very prosperous and worth further

exploration.

The overview of the proposed solution can be

found at

http://service.felk.cvut.cz/courses/XE36DBS

/xml/test/test.xml

for now only in Czech. However, for the camera

ready paper, the English version should be available,

including instructions the student were given and

the comments on the technologies used. Mozilla or

Firefox are recommended.

ACKNOWLEDGEMENTS

I would like to thank all the students who participated

in Databases 101 for their cooperation and comments.

This work has been supported by Ministery of Ed-

ucation, Youth, and Sports under research program

MSM 6840770014.

REFERENCES

Cheang, B., Kurnia, A., Lim, A., and Oon, W.-C. (2003).

On automated grading of programming assignments

in an academic institution. Comput. Educ., 41(2):121–

131.

Helmick, M. T. (2007). Interface-based programming as-

signments and automatic grading of java programs. In

ITiCSE ’07: Proceedings of the 12th annual SIGCSE

conference on Innovation and technology in computer

science education, pages 63–67, New York, NY, USA.

ACM.

APPENDIX A

Complete DTD for Final Work From

DBS

Explanation:

#PCDATA stands for an arbitrary string (text)

comment? zero or one occurence

of element comment

comment+ one or many occurences

of element comment

comment* zero, one or many occurences

of element comment

CSEDU 2009 - International Conference on Computer Supported Education

240

DTD speciﬁcation link (URL) can be included in each

XML document, so validating software can ﬁnd and

access it.

<!ELEMENT sproject (course, author, content)>

<!ELEMENT course (cname, code, semester,

seminar)>

<!ELEMENT author (aname, uname, email)>

<!ELEMENT content (declaration, title,

description, data_model, queries,

scripts, conclussions, references)>

<!ELEMENT cname (#PCDATA)>

<!ELEMENT code (#PCDATA)>

<!ELEMENT semester (#PCDATA)>

<!ELEMENT seminar (#PCDATA)>

<!ELEMENT aname (#PCDATA)>

<!ELEMENT uname (#PCDATA)>

<!ELEMENT email (#PCDATA)>

<!ELEMENT title (#PCDATA)>

<!ELEMENT declaration (#PCDATA)>

<!ELEMENT description (title, (para, comment?)+)>

<!ELEMENT data_model (title, dm_picture, comment?,

dm_discussion)>

<!ELEMENT scripts (title, (para, comment?)+)>

<!ELEMENT queries (title, dotazy, comment?,

pokryti_dotazu, comment?)>

<!ELEMENT conclussions (title, (para, comment?)+)>

<!ELEMENT references (title, (para, comment?)+)>

<!ELEMENT para (#PCDATA | link)*>

<!ELEMENT comment (para)*>

<!ELEMENT dm_picture (mediaobject)>

<!ELEMENT dm_discussion (para, comment?)+>

<!ELEMENT pokryti_dotazu (kategorie_dotazu+)>

<!ELEMENT kategorie_dotazu (entry+)>

<!ELEMENT entry (#PCDATA )>

<!ELEMENT link (#PCDATA)>

<!ATTLIST link

url CDATA #REQUIRED

<!ELEMENT dotazy (dotaz)+>

<!ELEMENT dotaz (popis_dotazu, comment?,

relacni_algebra?, comment?,

(sql, comment?)+)>

<!ELEMENT popis_dotazu (para)+>

<!ELEMENT relacni_algebra (#PCDATA)>

<!ELEMENT sql (#PCDATA)>

<!ELEMENT mediaobject (imageobject)>

<!ELEMENT imageobject (imagedata)>

<!ELEMENT imagedata EMPTY>

<!ATTLIST imagedata

fileref CDATA #REQUIRED>

A LARGE AMOUNT OF FINAL PROJECTS EFFECTIVELY PROCESSED WITH MINIMAL SOFWARE

REQUIREMENTS - Open Source and Platform Independent Solution: A Case Study

241