Mcce 2009 Proceedings
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Mcce 2009 Proceedings as PDF for free.
More details
- Words: 34,295
- Pages: 92
Proceedings of the 2nd Workshop on
Methods and Cases in Computing Education
Held in Barcelona (Spain), April 22nd 2009. Published by the Spanish Chapter of the ACM Special Interest Group on Computer Science Education with the collaboration of the Universitat Oberta de Catalunya.
www.uoc.edu
www.sigcse.es
ISBN XXX-‐XX-‐XXX-‐XXXX-‐X
Methods and Cases in Computing Education by Spain ACM SIGCSE Chapter is licensed under a Creative Commons Reconocimiento 2.5 España License.
[this page is intentionally left blank]
Foreword By Juan-‐Manuel Dodero, president of the ACM SIGCSE Spanish Chapter The ACM SIGCSE Spanish Chapter is the chapter of the Association for Computing Machinery (ACM) Special Interest Group on Computer Science Education (SIGCSE) serving Spain. It started operations in 2008. The chapter provides a forum for common problems among educators working to develop, implement and evaluate computing programs, curricula and courses, as well as syllabi, laboratories, learning technologies, and other elements of teaching and pedagogy. The Chapter supports activities complimentary to SIGCSE, the ACM, and other ACM activities in the Spain area. The Chapter is organized and operated for educational and scientific purposes, its aim being to increase knowledge about computing education, as well as to serve as a means of communication for those interested in this discipline. This workshop on Methods and Cases in Computing Education (MCCE) is the second of a series of events intended to the dissemination of the activities of the chapter members. As such, it will publish articles dealing with the joy, pain and hope of our daily teaching and research experiences in computing education. The MCCE workshop thus constitutes a forum open to anyone wanting to contribute to the chapter aims. The birth of the Chapter and the MCCE workshop, have the main objective of contributing to the discussions on the European Higher Education Area held among the Spanish Higher Education community. For the second edition of MCCE, held at Barcelona, a number of contributions were selected after a peer review process carried out by the chapter committee members and renowned international researchers.
i
[this page is intentionally left blank]
ii
Table of contents Experimental Inquiry into Greedy Algorithms ........................................................ 1
J. Ángel Velázquez Iturbide, Antonio Pérez Carrasco
SET (Software Engineering Tutor), a CASE tool to guide the creation of domain and use case models.................................................................................. 7
Sergio Bravo Martín, Francisco J. García Peñalvo, Miguel A. Conde González
Digital Systems Laboratory for Visually Impaired Students.................................. 13
Joaquín Olivares, José M. Palomares, Edmundo Sáez, José M. Soto
Design of an autonomous and cooperative robots laboratory............................. 23
Guillermo González-‐de-‐Rivera, Ricardo Ribalda, Angel de Castro, Javier Garrido
Database design using a web-‐based e-‐learning tool............................................ 31
Josep Soler, Imma Boada, Ferran Prados, Jordi Poch, Ramon Fabregat
The cost of learning and teaching Java in the Bologna process ........................... 41
Camino Fernández , David Díez, Jorge Torres, Telmo Zarraonandia
A High School Educational Platform based on Virtual Worlds.............................. 46
Mariano Rico, David Camacho, Xavier Alaman, Estrella Pulido
Comparing a fully online course to a blended one: the case of compilers............ 52
Salvador Sánchez Alonso, Daniel Rodriguez García, Robert Clarisó Viladrosa
Learning Engineering by Modeling a Guitar Effects Pedal with FPGAs ................ 61
Joaquín Olivares, José M. Palomares, José M. Soto, Juan C. Gámez
Using IMS-‐LD Standard to Support Learning in Teaching ICTs in Industrial Design Engineering............................................................................................... 71
Rocio Garcia-‐Robles, Fernando Díaz-‐Del-‐Río
Devising instruction from errors in students’ assignments: a case in usability engineering education ........................................................................... 79
Elena García-‐Barriocanal, Miguel-‐Angel Sicilia, Salvador Sánchez-‐Alonso, Daniel Rodríguez iii
[this page is intentionally left blank]
iv
Experimental Inquiry into Greedy Algorithms J. Ángel Velázquez Iturbide (1), Antonio Pérez Carrasco (1) (1)
Departamento de Lenguajes y Sistemas Informáticos I, Escuela Técnica Superior de Ingeniería Informática, Universidad Rey Juan Carlos Móstoles, Madrid, Spain {angel.velazquez,antonio.perez.carrasco}@urjc.es
Abstract Greedy algorithms are one of the most common algorithm design techniques. Unfortunately, they are usually taught and learnt in a passive way. In this paper, we propose a novel approach to active learning of greedy algorithms. The approach is based on experimentation with and evaluation of alternative greedy strategies for several problems. The approach is supported by an interactive assistant, named GreedEx. We also report on the results of its use in real lab situations, where we have evaluated the assistant usability and the students’ results.
1. Introduction Algorithms are a core subject matter of Computer Science. It has achieved a high degree of maturity, with most of its contents well-‐established. A number of algorithm design techniques are usually studied, such as divide-‐and-‐conquer, backtracking, dynamic programming, and greedy algorithms. The organization of greedy algorithms in most textbooks (e.g. (Cormen, T.H. et al., 2001), (Horowitz, E., and Sahni, S., 1978)) is not adequate for active learning. The chapter typically identifies the main elements of greedy algorithms, and states the technique as a high-‐level template. Besides, a set of representative problems is solved (we have cited above some of the most common). For each problem, an optimum greedy strategy is identified and stated recursively. Then its optimality is proved. Finally, the algorithm is coded iteratively and its time complexity is analyzed. This organization exhibits the following learning difficulties: •
Design of an optimal greedy strategy. It is easy for some simple algorithms (e.g. the coin changing problem), but it is much more demanding for others. To illustrate it more vividly, it is not realistic to expect from a student to design Dijkstra’s or Kruskal’s algorithm.
•
Coding a greedy algorithm. Most textbooks provide a high-‐level template. Greedy algorithms have the same semantics as the template, but their code is unique for each algorithm. Furthermore, some algorithms do not even fit this high-‐level template.
•
Proving the optimality of a greedy strategy. Most proofs are either by contradiction or by reduction, techniques that students are not very familiar with.
In summary, despite the apparent simplicity of greedy algorithms, their learning objectives are quite demanding. As a consequence, the instructor commonly gives lectures in a passive way, hardly letting place for active learning. On the student side, most problems solved with greedy algorithms are learnt by rote. In this extended abstract, we propose a new approach to active learning of greedy algorithms. In the second section, we introduce our approach, based on experimentation with and evaluation of alternative greedy strategies for a given problem. The third section describes our experience in using this approach in laboratories. Finally, we summarize our findings and outline future work. (A full version of this extended abstract will contain more elaborated version of every section. In 1
particular, we will describe support the assistants provide for active experimentation, will give a more elaborate analysis of the groups’ outcomes, a more extensive discussion and recommendations for future experiences, and related work.)
2. Active Learning of Greedy Algorithms by Experimental Inquiry In order to overcome the learning difficulties described above, we made an analysis of the different elements of greedy algorithms. We were especially interested in identifying elements that provided opportunities for active learning. We finally concluded that the key decision (and therefore most promising candidate) was the choice of an optimal strategy. Surprisingly, this decision taking is hardly addressed explicitly in textbooks. The only problem where a discussion involving suboptimal strategies can be found is the knapsack problem (e.g. (Horowitz, E., and Sahni, S., 1978)). Here, three strategies are typically considered, namely increasing order of weight, decreasing order of benefit and decreasing order of rate benefit/weight. We describe in the following subsection how to experiment actively with greedy strategies. A brief description of interactive assistant we developed to aid in experimental inquiry can be found elsewhere (Velázquez-‐Iturbide, J.Á., Pérez-‐Carrasco, A. et al., 2008). 2.1. Experimental Inquiry into Greedy Strategies We use in the article the activity selection problem (Cormen, T.H. et al., 2001), given that it is simple but not straightforward to solve. We may state it informally as follows. Given a set of n activities, each one with a start time si and a finish time fi, we seek to select a maximum-‐size subset of non-‐overlapping activities. For instance, given the set of activities in Table 1, the subset composed of activities {3,8,2} is a valid solution, while subset {9,5,4,2} is a maximum-‐size solution. Table 1. An instance of the activity selection problem. i
0
1
2
3
4
5
6
7
8
9
10
si
13
9
29
3
26
13
1
17
10
1
13
fi
15
24
30
7
28
20
6
27
29
13
15
The interesting issue here is trying to discover whether there is an optimal greedy strategy that solves the problem. Firstly, we should try to imagine as many candidate greedy strategies as possible. For instance, we may consider the strategies consisting in selecting activities based on the following nine criteria: •
Random.
•
Activity index in increasing/decreasing order.
•
Start of activity in increasing/decreasing order.
•
Finish of activity in increasing/decreasing order.
•
Duration of activity in increasing/decreasing order.
Of course, the first three strategies are no serious candidates to optimal strategies, but for the other six the choice is not obvious. If we experiment by applying the nine strategies to data contained in Table 1, we obtain the results in Table 2. These results allow us to discard the seventh and ninth strategies. We should now experiment again with the seven remaining strategies over new input data. (Although the first three candidates passed this first filter, they will likely drop soon.) 2
Table 2. Result of applying different strategies. Strategy
Activities selected
# activities
Random
[9, 4, 5, 2]
4
Index, increasing
[0, 2, 3, 4]
4
Index, decreasing
[9, 7, 2, 0]
4
Start time, increasing
[6, 1, 4, 2]
4
Start time, decreasing
[2, 4, 5, 3]
4
Finish time, increasing
[6, 0, 7, 2]
4
Finish time, decreasing
[2, 8, 3]
3
Duration, increasing
[2, 0, 4, 3]
4
Duration, decreasing
[8, 6, 2]
3
Performing as many times as necessary this experiment, we will reach a state where only those feasible strategies will survive. Following our example, we successively used five data sets and obtained the results summarized in Table 3. We only include the number of activities selected in each case. Table 3. Results over different input data. Strategy
1st run
2nd run
3rd run
4th run
5th run
Random
4
3
2
-
-
Index, increasing
4
3
3
2
-
Index, decreasing
4
3
3
1
-
Start time, increasing
4
3
3
1
-
Start time, decreasing
4
3
3
3
3
Finish time, increasing
4
3
3
3
3
Finish time, decreasing
3
-
-
-
-
Duration, increasing
4
3
3
3
3
Duration, decreasing
3
-
-
-
-
Notice that there are three remaining strategies. We could go on experimenting with new input data, or stop and try to formally prove the optimality of the three remaining strategies. Table 3 shows three candidate strategies to optimality; however, it must be noticed that one of them (namely, increasing order of duration) is not optimal.
3. Experience Several years ago we started the development of three assistants for different greedy algorithms: the knapsack problem, the activity selection problem, and the minimum cost spanning tree problem (including Prim’s and Kruskal’s algorithms). The maturity of these assistants differs. Assistants for the knapsack problem and the activity selection problem are mature programs, while the assistant for the minimum cost spanning tree problem is a working prototype. The usability of the two first assistants was evaluated by experts 3
(i.e. the instructor) and also by students in lab sessions. They gave us feedback about user acceptance, evaluation of the main features, and open suggestions. The results of usability evaluations were highly positive, and also allowed us to enhance their user interface and functionality. More information about the knapsack assistant and usability results can be found elsewhere (Velázquez-‐Iturbide, J.Á., Lázaro-‐Carrascosa, C.A., et al., 2008). We are currently integrating them into a single interactive assistant, called GreedEx. We use this name in the rest of the extended abstract. In the following subsections, we focus on the last evaluation. We describe the characteristics of the assignment and the outcomes of students with respect to the task assigned. 3.1. Protocol The laboratory evaluation was performed within the lesson on greedy algorithms. This chapter is a part of the course “Design and Analysis of Algorithms”, mandatory course for students of Computer Science. The evaluation was held in January 2009 and consisted in two sessions, being each session two hours long. A total of 24 students participated. Student work could be made individually or in pairs, but the opinion questionnaire that had to be made individually. Students were given the assignment statement, the assistant, a report model and an opinion questionnaire. Before the first session, the instructor had given the basics of greedy algorithms. He also had used GreedEx to illustrate the knapsack and the minimum cost spanning tree problems. In the first session, students had to perform three tasks: 1. Use the GreedEx interactive assistant to determine which of the strategies offered are optimal for the activity selection problem. 2. Fill and deliver a short report, following the model provided. 3. Fill and deliver the opinion questionnaire about GreedEx. Between both sessions, the instructor reviewed a number of relevant concepts, namely, hypothesis, experiment plan, refutation, counterexample, empirical evidence, and inductive and formal reasoning. At the beginning of the second session, the instructors identified which strategies were optimal, namely increasing order of finish time and decreasing order of start time. Students had to work within the same groups as in the first session. Depending on their findings in the first session, students had to make different tasks. For every strategy they had wrongly identified as optimal, they had to find any counterexample. For every strategy they failed to identify as optimal, they had to review their past experiments and find out why they failed to identify it. Their task had to be elaborated in a short report and delivered during the session. 3.2. Results The first session was performed by 31 students organized in 18 groups (13 pairs and 5 individuals). However, in the second session only 24 students participated, grouped in 11 teams (9 pairs and 2 individuals). We are interested in the strategies identified as optimal by the students. Table 4 shows the number of groups that proposed each strategy. It is not surprising that the optimal strategies are scored high. In fact, one of them (increasing order of finish time) was proposed by all the teams but one. A high number of groups (14) identified the strategy of increasing order of duration. This is not surprising, as it is a suboptimal strategy that delivers good results, as we showed in Section 2.1. Other suboptimal strategies 4
obtained zero or two votes. Table 4. Number of proposals per strategy. Strategy
# proposals
Random
0
Index, increasing
6
Index, decreasing
6
Start time, increasing
0
Start time, decreasing
14
Finish time, increasing
17
Finish time, decreasing
2
Duration, increasing
14
Duration, decreasing
0
There are two most surprising results. First, one of the optimal strategies only scored 14. Second, a relatively high number of teams (6) proposed the two strategies based on indices. We also are interested in analyzing how the groups performed in each independent session. With respect to the first session, we have the following results: •
All the groups but two only document between 2 and 5 runs to justify their selection. The other two groups run 9 and 13 input data, respectively and chose the correct strategies.
•
Two expected outcomes were: a group providing a reasoned rationale (either correct or incorrect), and a group without rationale. Other cases were: a group giving a meaningless rationale, a group giving a rationale dependent on a case (e.g. the list of activities being arranged in a specific ordered) or specific to each input data. Up to 5 groups provided a second optimization criterion to justify their selection of an optimal strategy. It seemed that they only could accept the existence of a single optimal strategy.
•
Some groups made wrong proposals based on a misunderstanding of the task to solve or due to previous misunderstandings. However, other groups were inconsistent in the process of analyzing the results of their runs.
There is a variety of groups that did not attend at the second session. Two groups had marked high in their first session, and four had performed poorly. With respect to their second task, most of the groups performed good.
4. Conclusions and Future Work Despite the apparent simplicity of greedy algorithms, it is difficult to learn them actively. We have presented in the paper a novel approach to active learning, based on experimentation with and evaluation of alternative greedy strategies. Consequently, the work here presented is a contribution to experimentation and the scientific method in CS education. Our approach is supported by the GreedEx interactive assistant. GreedEx has been evaluated for usability in real lab situations, having obtained high scores from students as well as useful information to enhance them. We have also reported on the successful performance of students 5
in their inquiry task. We plan to extend our work in several directions. Firstly, more problems can be integrated in GreedEx. Secondly, we are designing a fixed format for reports, which will also be supported by Greedex. Finally, we should make more emphasis in the future to proofs of optimality by students.
Acknowledgments This work was supported by project TIN2008-‐04103/TSI of the Ministerio de Ciencia e Innovación.
References Cormen, T.H., Leiserson, C.E., and Rivest. R.L. (2001). Introduction to Algorithms. The MIT Press, 2ª ed. Denning, P. et al. (1989). Computing as a discipline. Comm. of the ACM 32, 1, 9-‐23. Horowitz, E., and Sahni, S. (1978). Fundamentals of Computer Algorithms, Pitman. Velázquez-‐Iturbide, J.Á., Lázaro-‐Carrascosa, C.A., and Hernán-‐Losada, I. (2008). Asistentes interactivos basados en la taxonomía de Bloom para el aprendizaje de algoritmos voraces. IEEE Revista Iberoamericana de Tecnologías del Aprendizaje, accepted. Velázquez-‐Iturbide, J.Á., Pérez-‐Carrasco, A., and Urquiza-‐Fuentes, J. (2008). Active learning of greedy algorithms by means of interactive experimentation. In Proceedings of the 14th Annual Conference on Innovation and Technology in Computer Science Education, ITiCSE 2009, accepted.
6
SET, a CASE tool to guide the creation of domain and use case models in an introductory Software Engineering course Sergio Bravo Martín (1), Francisco J. García Peñalvo (1), Miguel A. Conde González (1) (1)
Universidad de Salamanca, Facultad de Ciencias Plaza de los Caídos s/n, 37008 Salamanca (España) {ser, fgarcia, mconde}@usal.es
Abstract The idea of using CASE (Computer Aided Software Engineering) tools in education as an interactive learning has been emerging for serveral topics in computer science. The learning process proves to be more effective, rapid and even persistent. This paper presents a CASE tool named Software Engineering Tutor (SET), which main aim is to improve the students’ knowledge in Software Engineering field, specifically to guide them in the domain and use case models construction. Besides, this tool offers a repository of case studies, trying to make an effort to share experiences around the university and professional community. Our experience with this tool, specially at the workshops of the Software Engineering subject during the last academic year, shows that SET is an useful tool for learners of such subjects and from student's very instructive. Moreover, it has become a key element of support for the continuous assessment introduced in the course.
1. Introduction Software Engineering, which traditionally has appeared like a discipline of Computer Science, is being considered in recent years as an entity separate curriculum, but with deep roots in the Computer Science and Mathematics. It offers methods or techniques for developing and maintaining quality software that solve all kind of problems. There are many CASE tools that provide support to Software Engineering and contribute greatly to increase productivity in software development reducing the cost in terms of time and money. These tools are applied in all aspects of the lifecycle of software development such as planning, analysis, design, project documentation (textual and graphical), automatic code generation and error detection, and so on. This paper presents a new CASE tool named Software Engineering Tutor (from now on SET), designed to provide support in the early stages of the lifecycle. It particularly focuses attention in requirement engineering and analysis stage, with the facility to create use cases and domain models respectively. But the elements that differentiate SET from other tools are the innovative teaching approach and the self-‐training for the software engineer, due to a modeling wizard that guides the user step by step in the building models. SET has been developed by a Final Project at the Computer Science Department of the University of Salamanca, and specially used in the practical part of the Software Engineering subject at the third course of the Computer Science Degrees. The article is divided in the following sections: Section 2 gives a review of the context subject and the continuous assessment process introduced since the academic year 2005-‐06, and how SET fits in this strategy. Section 3 describes functional characteristics of SET. Finally, we present the conclusions taken from this case study. 7
2. Software Engineering subject: context and assessment process Software Engineering has great important in the curriculum of Computer Sciences Engineering because it is essential to have strong knowledge about developing software and all the stages of its lifecycle, beginning with the necessity of building a system, passing throw the implementation and ending with the software maintenance. This subject shows to the students a set of principles that are regularly and systematically applied in designing and constructing economically viable computer software tasks. In order to understand the different topics is necessary that the student will be capable of performing a job for reflection, assimilation and practice of different underlying topics of the program subject. Encouraging these disciplines and considering that in most cases students apply every effort only to pass, it becomes necessary to apply a methodology for continuous assessment. 2.1 General concepts of the subject The course comprises 60 hours (45 theoretical hours and 15 lab hours) and tries to focus attention on the following topics:
Lifecycle and process requirement elicitation and documentation.
Analysis and design methods and notation.
Modularity, software architecture, and software reuse principles (design patterns and reusable solutions perfectly valid).
The presentation of these topics emphasizes abstraction as the fundamental technique for understanding and solving problems (Wasserman, 1996). Somewhat, this is the main problem that students suffer at this course, because of the experience of the analyst role is very important and there is not a scientific method or technique to complete the early stages of the lifecycle of software development. This handicap is exacerbated further in Engineering Degrees in those object modeling is taught in first courses. The traditional way to perform the practical part and assimilate the knowledge required by this subject is developing a small engineering project (Chamillard, 2002), at least as far as the analysis and design stages. However, it is necessary to supplement the practical part with a series of workshops (Garcia, 2004) that cover the following topics:
one workshop devoted to the entity-‐relationship model, in order to review conceptual data modeling principles,
two workshops devoted to introducing the object-‐oriented analysis using Unified Modeling Language (OMG, 2004) as the modeling language (from now on UML), in order to build domain models (class diagrams) and,
last workshop devoted to introducing the basic principles of use case diagrams, using again UML (Rumbaugh, 2005), and like a first approximation to requirements engineering.
According to this idea, SET aims to support young students in the stages of requirement engineering and analysis, particularly in the construction of domain and use case model covered in the last three of the four workshops planned for the course. 2.2 Assessment process In addition to the traditional evaluation system, students can optionally choose a continuous 8
assessment, in which attendance and active participation play an important role. The implementation of continuous assessment, in the context of this subject, is a major challenge, therefore should be implemented on two large groups with approximately 100 students each one (Garcia, 2008). This evaluation system provides continuous on-‐line information about subject that can contribute to improve or even redirect the process of student learning. However, teachers need the tools and suited methods to know the feedback on the degree of learning of student during the course. This is one of the most important benefits of using SET in order to support the process of continuous assessment, through the homogenization of the reports submitted. 2.3 Introducing SET in the learning and assessment process In order to apply a methodology for continuous assessment at the subject, the teachers need agile and effective mechanisms to obtain the learning degree of students over the course. During the last academic year, the subject of Software Engineering has used two support tools in the learning and assessment process: 1. Studium (supported by Moodle), an online virtual campus for the subject, with the following resources:
Contents described at the program subject and presented at attending classroom.
Forums to control the students’ participation over the course.
Forms to collect the reports required at workshops and voluntary exercises.
2. SET (Software Engineering Tutor), a learning tool with the following competences:
Supporting the teacher at attending classroom to present theoretical concepts about object modeling techniques.
Guiding the software engineer (or student) in the use case and domain models creation.
Normalizing the practical workshop or exercises reports.
3. Functional description of SET The key features of SET, currently in version 1.0.7, focus primarily on the following topics:
a modeling wizard as a mechanism to support the construction of use case and domain models,
a standard mechanism to make personalized and normalized reports,
a central repository of such case studies,
compatibility with other CASE tools using XML Metadata Interchange (from now on XMI) and desktop programs, and
user interface based on different views of the model under construction.
3.1. The modeling wizard The original idea of Software Engineering Tutor is mainly to introduce the student (or software engineer) at the requirement engineering and object-‐oriented analysis stage by the use case and domain models construction. Both models are built graphically using UML diagrams. However, its 9
contribution in the real world of CASE tools lies in their orientation on training and instruction in building such models using an integrated modeling wizard. This intelligent wizard makes SET a unique tool. The modeling wizard is a dialog box that allows the user to navigate freely through a set of steps that guides the process of building models. All strategies used to design the wizard (i.e., the identification of conceptual classes based on lists of categories) are taken from the literature (Larman, 2002). Regarding the domain model, the techniques used for the design of the wizard are the following:
Identification of conceptual class (using category list).
Identification of associations.
Identification of attributes.
Identification of superclasses and subclasses.
Identification of whole-‐part relationships.
In addition to Larman’s techniques, it is also possible the identification of conceptual classes using the method describe at (Coad, 1990). The steps of the use case model wizard are also based on Craig Larman indications too. Each step is presented in a concise way and with the necessary controls, so that users can complete perfectly. Moreover, there is the option to extend the information on the current step, with detailed instructions (and examples) on how to complete it.
Fig. 1: Domain modeling wizard The wizard is fully associated with the main frame of the application, so that both workspace environments will work on the same data. In this way, the effects produced by actions in the wizard will be instantly visible at the workspace. 3.2. Normalized reports The tool allows to the user printing reports of a project (previously saved) and exporting them to Portable Document Format (PDF). In addition, it is able to create own report types. This functionality offers to the teachers the possibility to normalize the reports at the practical workshops and even in the volunteer exercises delivered. In this way, the evaluation of the reports 10
is more agile and at the same time is possible to ensure the originality of the work and, for example, the detection of plagiarism. 3.3. Central repository Any tool that provides a teaching approach requires a basic knowledge and useful learning support. In our case, SET provides to the university community a wide range of well-‐known case studies that serve as examples and support for students. According to this approach, SET uses the template concept as a default case study (or standard model). It provides to SET the power to build new models from existing ones. In order to generalize the use of the tool, and particularly the availability of the templates catalog, the Computer Science Department of the University of Salamanca has created a virtual space on Internet (available at http://set.usal.es), with a central repository of a set of standard templates with solutions to well-‐known case studies. These templates can be viewed and downloaded directly from the repository without leaving the workspace. In addition, the repository is ready to interact with it only registered users.
Fig. 2: SET workspace with the four views 3.4. Compatibility SET can be exported according to the XMI standard (XML Metadata Interchange) for exchange diagrams (OMG, 2007). In this way, the tool does not become a close application, but it is supplemented with other CASE tools that provide support in other stages in the software development lifecycle. It could be said that, although this tool provides the user on everything needed for the construction of diagrams related to the domain model and use cases, the main purpose of SET is not to draw diagrams, but tutoring and assisting in the creation of these models. 3.5. User interface based on different views The workspace of the case tool is divided into four views that provide different perspectives of the 11
model under construction (see Fig. 3): model (elements model in a tree view), diagram (current model in diagrammatic form), properties (properties of the selected element of the current model) and console view (text read-‐only with a history of all relevant actions from the current model). 4. Conclusions SET aims to be the germ of a new type of CASE tools for the training of future software engineers. The learning process is marked by a complete and proven wizard that guides the construction of domain and use cases models. One of the benefits on the assessment process after incorporating the tool on practical workshops on the subject of Software Engineering has been the unification of all documents by the automatic generation of reports functionality. Also, the initiative of the case studies central repository not only expands the possibilities of using the tool but also sharing other cases made by other members of the academic community or professionals. Moreover, due to the distributed nature of this case tool, we find the possibility of working with the client application in offline mode. Finally, the compatibility with the UML and XMI standards allows that the SET models can be used in other case tools or desktop applications.
Acknowledgment This work is partially supported by the Regional Ministry of Education of Junta de Castilla y León through the project GR47.
References Chamillard, A.T. , Braun, K.A. (2002). The software engineering capstone structure and tradeoffs, In Proceedings of the 33rd SIGCSE Technical Symposium of Computer Science Education— SIGCSE’02, pp 227–231. Coad, P., Yourdon, E. (1990). OOA Object-‐Oriented Analysis, Prentice-‐Hall García, F.J. and Moreno, M.N. (2004). Software Modeling Techniques for a First Course in Software Engineering: A Workshop-‐Based Approach. IEEE Transactions on Education, Vol. 47, No. 2. Garcia, F.J., Conde M.A., Bravo, S. (2008). Continuous Assessment in Software Engineering, In Proceedings of the Methods and Cases in Computing Education, MCCE ‘08, Salamanca, Spain, pp 41-‐46. Larman, C. (2002). Applying UML and Patterns: An Introduction to Object-‐Oriented Analysis and Design and the Unified Process, 2nd Edition, Prentice Hall OMG (2004). Unified Modeling Language: Superstructure. Version 2.0. Object Management Group Inc. Document formal/05-‐07-‐04 [on line]. Available on: http://www.omg.org/cgi-‐ bin/doc?formal/05-‐07-‐04 [Last visit, sep-‐2008] OMG (2007). MOF 2.0/XMI Mapping, v2.1.1. Object Management Group Inc. Document formal//2007-‐12-‐01 [on line]. Available on: http://www.omg.org/docs/formal/07-‐12-‐01.pdf [Last visit, sep-‐2008] Rumbaugh, J., Jacobson, I., Booch, G. (2005). The Unified Modeling Language. Reference Manual. 2nd Edition, Addison-‐Wesley Shlaer, S., Mellor S. J. (1988). Object-‐Oriented Analysis: Modeling the World in Data. Yourdon Press Wasserman, A. (1996). Toward a discipline of software engineering. IEEE Software, Vol. 13, 23–31. 12
Digital Systems Laboratory for Visually Impaired Students Joaquín Olivares, José M. Palomares, Edmundo Sáez, José M. Soto Department of Computer Architecture. University of Córdoba. Campus Rabanales. 14071. Spain {olivares,jmpalomares,edmundo,jmsoto}@uco.es
Abstract This paper describes how the practical sessions of the Digital Systems Laboratory within the Computer Science Degree have been adapted to allow a visually impaired student to take part in the practical sessions. Regular students use a computer-‐-‐aided design tool (OrCAD) for digital design in their practical assignments. This work shows how the use of special instrumentation allows visually impaired students to work with regular students in the same lab, where the CAD tool is installed. The teaching methodology and the obtained assessments are introduced here. Some specific practical materials have been designed and they are described in this work; the design of a special buzzer is also presented.
1. Introduction The subject known as Computers Structure and Technology is scheduled for the second semester of the first academic year in the Computer Sciences Degree in the University of Córdoba, Spain. It consists of 45 theoretical hours, 15 hours of exercises, and 30 hours for practicals in labs. Four theoretical hours a week are given, including theory and exercises, while two practical hours a week are given in labs. The course lasts for 15 weeks. This information is all summarized in Table 1. Table 1. Course description Lectures (4h./week)
Week Laboratory (2h./week)
1. Introduction. General overview
1
Lab. equipment and safety
2. Information representation
2
CAD tool introduction
3. Boole Algebra. Logic gates
3
Simulating logic gates
4
Minimisation
5
NAND, NOR synthesis
5. Combinational design
6
Combinational I
6. Combinational logic circuits
7
Combinational II
8
Adder/Subtracter
4. Logic functions. Minimisation
7. Digital arithmetics 8. Digital artihmetics circuits
9 10 11
9. Sequential systems
12 13
10. Sequential circuits
14 15
Arithmetic Logic Unit (ALU) Counters RAM memory Laboratory examination
The main objective is to introduce the basic concepts underlying the digital systems, as well as the instruments used to design digital electronic circuits. In the laboratory, the students use the 13
OrCAD tool to design simple combinational, arithmetic, and sequential circuits. A visually impaired student (VIS) enrolled in this subject. He was not able to perform the lab sessions with the CAD tool due to his impairment. Thus, an alternative method was needed. The goal of this paper is to describe this alternative method. This particular experience is to be considered as a starting point for teaching Digital Systems to visually impaired students (VISs).
2. Course Description of the Practical Sessions Below, the proposed practicals are described:
1st Week Laboratory equipment and safety. In this session, the lecturer introduces the practical sessions, shows the lab to the students, explains the safety rules and informs the students about the emergency exits. 2nd Week CAD tool introduction. The second session is used to teach the students some concepts about the operating system (OS), their OS accounts, and to perform an introductory tour about OrCAD, showing the main characteristics of this tool. 3rd Week Simulating logical gates. Students learn how to design a basic circuit using logical gates, input and output ports, and wires. The process to compile, stimulate, and simulate a circuit is also shown. How to understand the graphical simulation is also explained. 4th Week Minimisation. Simple combinational problems are simplified using Karnaugh maps. Afterwards, students implement the solution in OrCAD and simulate it to check its validity. 5th Week NAND and NOR Synthesis. Students apply the universality of the NAND and NOR logic gates. 6th Week Combinational I. To familiarize students with real cases, simple problems are described. Students should first obtain the truth table, perform Karnaugh simplification, obtain the logical equation that represents the solution, turn the equation into a schematic design, compile it, and finally, stimulate and check that the simulation is correct. 7th Week Combinational II. More complex problems are introduced in this session. These problems require the use of buses. 8th Week Adder/Subtracter. In order to introduce the students to binary arithmetic, a 1-‐bit full adder (FA) is designed. Then, students use this component to design a 4-‐bit FA. Next, using two's complement, students design a 4-‐bit subtracter using the adder which was previously designed. Concepts of hierarchical designs are introduced. 9th-‐10th Week Arithmetic Logic Unit (ALU). A 4-‐bit ALU capable of performing 8 different operations, is implemented within this practical session. 11th-‐12th Weeks Counters. The design of a modulo-‐6 up/down counter is proposed to introduce students into the sequential systems. Synchronous and asynchronous signals are studied. 13th-‐14th Weeks RAM Memory. Students are asked to design a 4 x 3 RAM memory, with one bidirectional 3-‐bit data bus. It provides the students with the concepts of memories, bidirectional ports, and tri-‐state buffers. 15th Weeks Laboratory examination. Students are asked to design, implement, and simulate one exercise based on the previous sessions. 14
3. A visually impaired Student University of Córdoba informed the professors a few months before the course started that a student called Rafael (Rafael allowed the use of his name and photographs within the academic scope.) enrolled in the subject described above. He presents a visual impairment that consists in just 12% lateral vision in the right eye, while the left eye is totally blind. He is able to read Braille proficiently. He is able to recognize different colours presented in large lines. However, he needs to approach his face to the drawing very closely. This impairment prevents him from performing the practical sessions with the OrCAD tool. Thus, a different approach was needed. This approach should give Rafael similar knowledge to that acquired by the other students. First of all, a search in the scientific literature for different strategies for teaching Electronics, Digital Systems, or similar subjects to VISs was carried out. A small amount of works in this field were found. Some of them, which are the most representative ones, are stated below. In (Graham et al., 2007), an initial study on interface design for VISs is presented. In this work from the Computer Science at Ulster and Electronics at York, they obtain one main conclusion: touch is best for orientation in schematics. They also recommended suppressing superfluous information. However, no experimental results are shown in the article. (Bel and Bradburn, 2008) present a basic study about materials and accessibility, based on a questionnaire distributed among teachers. Results suggest that professors show a lack of technical knowledge that prevents them to use the technical material properly. In (Harrison et al., 2008), the authors present a preliminary work to collect information for a future Virtual Learning Environment (VLE) tool. This VLE tool was expected to be an interesting starting point for adapting the practices for Rafael; however, current VLE platform is not available for severe VISs or blind people. (Rodríguez-‐Ascaso et al., 2008) show a work in progress about personalized support to students with disabilities based on some educational guidelines for higher education. Conclusions are not yet obtained, and thus, those guidelines have been used just as suggestions. All these works in progress about accessibility in education for students with disabilities are theoretical proposals without any experimental results. Currently, interface design for VISs predominantly includes Tactile User Interfaces (TUIs) or Audio User Interfaces (AUIs) (Benyon et al., 2005). Several authors have stated the importance of the tactile abilities for blind students (Tubiana et al., 1984), (Rogow, 1987), (Rogow, 1990), (Mommers, 1975). Other authors (Fricke and Baehring, 1994), (Huang al., 2004), have made use of different instruments to control systems using audio interfaces. Thus, the proposed solution was to substitute the practical sessions using the CAD tool with other using real lab instrumentation which could be controlled by means of the hearing and touch. On the other hand, in order to make the integration of Rafael with the rest of the students easier (Stovall and Sedlacek, 1983), the instrumentation to be used is taken to the lab where those students are working. Fig. 1 depicts this situation.
4. Practical Material and Instrumentation As it has been stated previously, Rafael is able to read Braille. This fact is quite common in most visually impaired students (Gray and Wilkins, 2005), and thus, most of the subjects previously translated to Braille are available for new students. However, in this case, after a deep search helped by ONCE (Spanish National Organisation for the Blind), there were not found any VIS who had attended a Digital Circuit lab within Computer Sciences Degree in Spain. Therefore, the first task was to translate all the written course material into Braille. All the used diagrams were also embossed and coloured. 15
Fig. 1: Rafael and other students at laboratory. In the search for methods for the adaptation of the assignments for Rafael, different solutions were considered. Two of them have been frequently used in assisting visually impaired people: Windows Magnifying Glass (Pyy et al., 2007) and JAWS Software (Freedom Scientific, 2009). However, they were not applicable within this scope. Windows Magnifying Glass is useful when the visual impairment is not severe. The method described in this work is designed for seriously impaired people, even for blind people. Therefore, Windows Magnifying Glass was discarded. JAWS Software is useful when the impaired person works with textual information. In this case, the electronic designs are represented using schematics. Thus, JAWS Software has not been a great help for this work. After that, other solutions were investigated. Several attempts using a voice synthesizer software capable to read the screen (Barry, et al.1994) with OrCAD design software were tried. However, this produced unsatisfactory results and thus, it was rejected. Finally, it was decided not to use OrCAD software and to adapt the assignments to be able to implement them using physical circuits. Moreover, the fact that the impaired student could work with real devices, instead of with CAD tools, was considered to be very interesting. 4.1.
The Generic Protoboard
VISs use their fingertips to read, to locate elements, etc. They are able to locate chips and to count every pin of them. However, these pins are too close to each other and sometimes they find hard to plug cables attached to those chips. In order to help the tactile guidance of the VIS throughout the chips involved in the implementation of the different assignments, a generic protoboard was used. This protoboard allows the use of different 74LSxxx chips. The chips needed in the design of the solution of the laboratory assignments are plugged in the sockets of this protoboard. Each chip socket has a plastic piece to unplug each chip easily and without damaging its pins. By using this protoboard, pins are guided by wires to separated sockets, much easier to manage by VISs than the standard pins in the chips. 4.2.
Embossed Cardboard of the Chip
Several days before each session, a cardboard with a design of every chip is given to Rafael. This cardboard is designed using Braille for the text and embossed and coloured lines for the electrical connections. Different chips are identified by Rafael, and he situates them close to the protoboard 16
in an order that allows him to remember each one and lets him locate and use the documentation translated into Braille of each chip. 4.3.
Proposed Practical Material and Instrumentation
Standard lab instruments have been used, but as other authors have done (Fricke and Baehring, 1994), one instrument was specifically designed to perform the proposed assignments (the buzzer) and another was adapted to be used by VIS (small modifications on the protoboard). The proposed instrumentation comprises:
A 5V continuous current power supply used for TTL logical devices.
A clock generator device.
A generic protoboard which allows discerning between the pins of a chip by touch. Small modifications have been carried out on the internal connection lines of this protoboard, as well as on the ground and power lines, which are embossed in order to be easily identifiable. To differentiate between them, power lines are coloured in red, while ground lines are coloured in black. If other students are not able to differentiate between colours, the embossed lines could be modified using different textures.
A specially designed buzzer. It consists of one terminal that can be easily connected to any of the protoboard pins in order to perform voltage measure. The buzzer volume can be easily adjustable due to the variable impedance that has been incorporated. A logical 1 activates the buzzer, while a logical 0 produces no sound. The buzzer design is illustrated in Fig. 2a. The device is shown in Fig. 2b.
Cables with connectors for the protoboard.
Some chips from the TTL 74LSxx family. The student is given special instructions about the encapsulation and how to identify the different pins.
It is to be mentioned that all these practical material and instrumentation have been designed and built in a low-‐cost basis because no extra funds were given for this project. The only external body which provided some help was ONCE: a printing device able to print in relief, which was used to print Braille texts and schematics.
Fig. 2, a): The Buzzer design. b) The Buzzer
17
4.4.
Security Issues
With regard to the security issues, they are described to Rafael in the first week of the practical sessions. Rafael's workplace is located close to the exit and out of the way out. Thus, the other students could easily evacuate the classroom in case of emergency. Furthermore, the student situated closer to Rafael would help him in his way out of the lab. The equipment used by Rafael has low voltage and amperage. And therefore, no additional security measures are needed.
5.
Description of the Adapted Assignments for Visually Impaired Students
In this section, the different assignments adapted for VISs will be described. hey have been designed to be feasible for other visually impaired students. The practical sessions are the following: •
1st Week Laboratory equipment and safety. In this session, the lecturer introduces the practical sessions, shows the lab to the students, explains the safety rules and informs the students about the emergency exits. The student with the visual impairment sits in a special table close to the lecturer and to the main exit of the lab. In an emergency case, he should follow the instructions given by the lecturer. Moreover, the student that is closest to the one with the impairment is trained to help him to evacuate the lab if it is needed.
•
2nd Week Lab instrumentation introduction. The student is instructed about the use of the instrumentation listed in Section 4.
•
3rd -‐ 4th Weeks Getting used to the instrumentation and logical gates. This session is used to familiarize the student with the instruments. The student verifies the truth table of the several TTL logic gates. He learns how to stimulate logic gates. Different gates are given to the student and he is asked to identify each of the gates, interpreting the truth table obtained using the buzzer.
•
5th Week NAND and NOR Synthesis. The student applies the universality of the NAND and NOR logic gates simultaneously with his classmates. At the end of the session, he is able to easily identify the logic state of inputs and outputs of the logic gates.
•
6th Week Combinational I. This session is similar to that performed by the rest of the students using OrCAD. He designs the solution before the practical session, and once in the lab, he implements it and checks it.
•
7th Week Combinational II. This session is also similar to that performed by the rest of the students. More complex problems than those proposed in the past session are proposed in this assignment. At the end of the session, the student has achieved the same level of knowledge in digital logic design as the other students, except for the information about OrCAD.
•
8th – 9th Weeks Adder/Subtracter. The student is introduced in the field of digital arithmetic by the implementation of a 1-‐bit full adder. This task is also scheduled to regular students. After that, a 2-‐bit full adder is designed, instead of the 4-‐bit full adder implemented by his classmates. This is due to the higher complexity of the physical designs against simulated designs. However, the knowledge acquired by the student is equivalent. Finally, an adder/subtracter using two's complement is implemented.
•
10th Week Combinational MSI (Medium Scale Integration) Devices I. The design of an ALU requires a great number of connections and components. Therefore, it is not possible for a VIS to tackle with such a design. Instead, the student is asked to design the Logic Unit only, using a 18
74LS151 multiplexer and a function generator to test all the possibilities. •
11th Week Combinational MSI devices II. The student designs simple combinational circuits using a 74LS138 decoder. The technique to use a decoder as a demultiplexer is also introduced.
•
12th Weeks Counters. The student works with a 4-‐bit binary counter (74LS161) and a decade counter (74LS162). Then, he designs an 8-‐bit decade counter using two 74LS161 modules, applying carry propagation.
•
13th Week Registers. In this session, the student works with a 4-‐bit register (74LS194), which allows parallel and serial access, as well as left and right shift. During 12th and 13th sessions, the concepts of synchronous systems, clock edge, and sequential systems are introduced.
•
14th Week Flip-‐flops. In order to understand the functionality of memory elements, a JK flip-‐ flop (74LS112) is used. The four possible inputs of the flip-‐flop are tested. A 2-‐bit asynchronous counter using a JK flip-‐flop is also designed.
•
15th Week Laboratory examination. This session is not necessary, as the student is continuously evaluated.
A comparison between the assignments performed by regular students and those proposed to VISs is given in Table 2. Apart from the practical sessions in weeks 1, 2, and 15, used to get in touch with OrCAD and to examine the students, they must complete eight assignments. In weeks 3 to 8, a VIS solves the same assignments than the other students. In week 9, a VIS implements part of an ALU. Regarding the counter, a VIS designs an 8-‐bit decade counter using MSI circuits, instead of using logical gates as his classmates. At the end, a VIS studies the flip-‐flop as the basic memory element, and uses it to design registers. On the contrary, the rest of the students design a full 4 x 3 RAM memory. While regular students perform 9 assignments (weeks 3 to 14), a VIS completes 10. However, the practical sessions in weeks 10th and 14th are reduced versions of the equivalent assignments for the other students (part of an ALU in week 10th and flip-‐flops instead of RAM memory in week 14th). Thus, it is expected that a VIS is able to acquire a similar level of knowledge as the rest of the students. Table 2. Laboratory course comparison Visually impaired student
Week Other students
Lab. equipment and safety
1
Lab. equipment and safety
Instrumentation introduction
2
CAD tool introduction
3
Simulating logic gates
4
Minimization
NAND, NOR synthesis
5
NAND, NOR synthesis
Combinational I
6
Combinational I
Combinational II
7
Combinational II
8
Adder/Subtracter
Basic logic gates
Adder/Subtracter
9
Combinational MSI I
10
Combinational MSI II
11
Counters
12
Registers
13
Flip-flop
14
19
Arithmetic Logic Unit (ALU) Counters RAM memory
Unused
6.
15
Laboratory examination
Evaluation
After presenting the adapted assignments, the evaluation of Rafael with those assignments is shown. Each practical assignment, previously translated into Braille, was proposed to Rafael at least two weeks in advance. Thus, Rafael prepared the formulas and the resolution of each practical before coming to the lab. The qualification of each practical was obtained using several principles such as attendance to the practical sessions, theoretical development of each practical, implementation (in particular, good organization, cleanness, and tidiness of the design in OrCAD), and finally and most importantly, the correctness of the solution provided. These principles were applied to all the students, both VIS and non-‐VIS. Every student is awarded several points depending on their attendance, on the theoretical development of each practical, on the description of the implementation (taking into account, the organization, cleanness, and tidiness of the implementation of every practical), and above all, on the solution they provide. In order to pass the subject, students have to obtain at least 50% in each of the proposed assignments. 6.1.
Examination Results
According to those principles, Rafael obtained an overall qualification of 9.65 points (out of 10), which is highly remarkable. Rafael was an outstanding student and obtained a qualification grade of “A”. The score for each practical is shown in Tab. 3. There, “Partial Score” stands for the score obtained by Rafael in every practical; every practical is weighted using “Practical Weight” to sum up the final value; “Practical Score” is the value obtained by Rafael weighted in order to compose the “Global Score”. “Practical Score” and “Global Score” are ranged from 0 to 10. In order to make a comparison with other students, several statistics about their evaluation are given. 47% of the students failed (obtained a result below 5 in any of the assignments). 27% of the students passed the assignments obtaining a “C” grade (in the range of 5 to 7). 11% of the students received a “B” grade (ranging from 7 to 9), and 15% of them were awarded an “A” grade (above 9). No student obtained an “A+” grade. As can be deduced from the results stated previously, most students pass the assignments, however, only few of them could obtain such a high grade, and Rafael was one of those students who obtained an “A” grade. Table 3. Evaluation of the VIS Teaching Results Adapted assignments for the Visually Impaired Student
Partial Score
Practical Weight
Assignment Score
Lab. equipment and safety
—
—
—
Instrumentation introduction
—
—
—
Basic logic gates
100 %
5%
0.5
NAND, NOR synthesis
100 %
5%
0.5
Combinational I
100 %
5%
0.5
Combinational II
90 %
10 %
0.9
Adder/Subtracter
100 %
15 %
1.5
Combinational MSI I
100 %
10 %
1.0
Combinational MSI II
90 %
10 %
0.9
Counters
90 %
15 %
1.35
Registers
100 %
15 %
1.5
20
Flip-flop Global score (over 10)
6.2.
100 %
10 %
1.0 9.65
Teaching Assistance
A VIS requires much more guidance than a non-‐VIS: for instance, a VIS can plug incorrectly a cable into a socket (not properly plugged, or plugging it in a nearby socket, etc.) It is also very common to guide the finger of a VIS to the first socket of each chip. The professors were advised in advance by Rafael and his tutors about some of these inconveniences. Due to that, a classmate and an assistant professor were assigned to help him. In most of the assignments, Rafael required a constant assistance from the assistant professor. Most times, the help required was that of taking his finger to the first socket of each chip used in the solution. Sometimes he also asked for help when debugging. In this task, most of the mistakes were due to wrong insertions of the cable into the sockets: he did not plug completely the connector into the socket. Rafael required little assistance from the assistant professor only in the first practical session, which was the easier one. Thus, his behavior about asking for help from the professor is similar to the one of his classmates: the only difference was that his requests for help was more continuous.
7.
Conclusions and Enhancements
Three main aspects of this work are to be emphasized in this section. At first, the integration of a VIS with his classmates. At second, the learning process of the student. Finally, the lecturer assistance, which is required. Finally, some enhancements are suggested to improve this work. VISs are able to carry out their work at the same time and in the same location as the other students. The fact that these students are not treated differently than their peer helps minimize any perception of preferential or discriminatory treatment. The opposite was also achieved: most non-‐VISs showed interests in performing their assignments using the same platform that Rafael used. The learning process of a VIS has been designed to be easily affordable. In particular, the experience with Rafael has been highly positive as the student has notably assimilated the knowledge required in this course, mainly due to the high motivation he used to face the practical sessions. On the contrary, the main weakness of this system is that the assistance of an additional lecturer is required. During the first five weeks, one sole lecturer is able to manage the situation. However, since week 6th, regular students require much attention from the lecturer, mainly due to learning problems with OrCAD. Thus, a second lecturer to assist the VIS is needed. In general, to count on two lecturers since the beginning of the course is advisable.
Acknowledgements The authors would like to thank Prof. Dr. Manuel Hernández Calviño for his inestimable support and interest. This work was partly supported by the Xilinx University Program and the Vice Chancellor of European Higher Education Area and Undergraduate Degree Programs.
References W.A. Barry, J.A. (1994) Gardner, and T.V. Raman, Accessibility to Scientific Information by the Blind: Dotsplus and ASTeR could make it easy, in Proceedings of the 1994 CSUN Conference on 21
Technology and Persons with Disabilities, USA. E. Bel and E. Bradburn (2008), Reframing Teachers' Conceptions of Accessible E-‐Learning Designs, in Proceedings of the IEEE International Conference on Advance Learning Technology. 1023-‐1027. Santander, Spain. Benyon D., Turner P., and Turner S. (2005), Designing for Interactive Systems, Addison Wesley 104; 404-‐417. J. Fricke and H. Baehring (1994), Design of a tactile graphic I/O tablet and its integration into a personal computer system for blind users, Electronic Proceedings of the EASI High Resolution Tactile Graphics Conference. Graham D., Benest I., and Nicholl P. (2007) Interaction Design For Visually Impaired Students: Initial Findings, 8th Annual Conference on the Teaching of Computing. Southampton, UK. G. Gray and S.M. Wilkins (2005), A snapshot of 2003-‐4: blind and partially sighted students in Higher Education in England and Northern Ireland, British Journal of Visual Impairment: 23(1), pp. 4—10. M. Harrison, C. Stockton, and E. Pearson, (2008) Inclusive, Adaptative Design for Students with Severe Learning Disabilities, in Proceedings of the IEEE International Conference on Advance Learning Technology. 1023-‐1027. Santander, Spain. J-‐Y. Huang, M-‐C Tung, M.W. Kuei, and K-‐J. Chang, (2004) A user interface for the visual-‐ impairment, Displays: 25(4), pp. 151-‐157. Freedom Scientific, Inc. JAWS for Windows Headquarters Website http://www.freedomscientific.com/jaws-‐hq.asp . M.J.C. Mommers, (1975) Some factors related to Braille reading by blind children in elementary schools, The Louis Braille British conference on research into reading and listening by the visually handicapped, Cambridge, UK, pp. 26-‐46, 1975 H. Pyy, C. O'Donnell, and F. Monteiro de Carvalho (2007), Virtual Magnifying Glass 3.3, http://magnifier.sourceforge.net, 1999-‐2007. A. Rodríguez-‐Ascaso, et al. (2008) Personalised support for students with disabilities based on psycho-‐educational guidelines, in Proceedings of the IEEE International Conference on Advance Learning Technology. 1021-‐1022. Santander, Spain. S.M. Rogow, (1987) The ways of the hand: a study of hand function among blind and visually impaired multihandicapped children and adolescents, The British Journal of Visual Impairment: 5(2), pp. 59-‐61. S.M. Rogow, (1990) The development of hand function in young visually impaired children, Realities and opportunities: Early Intervention with Visually Handicapped Infants and Children, Proceedings of the International Symposium of Visually Handicapped Infants and Young Children, American Foundations for the Blind. Royal National Institute for the Blind (RNIB) National Centre for Tactile Diagrams (NCTD) \url{http://www.nctd.org.uk C. Stovall and W.E. Sedlacek, (1983) Attitudes of male and female university students towards students with different physical disabilities, Journal of College Student Personnel: 24(4), pp. 325— 330. R. Tubiana, J.M. Thomine, and E. Mackin, (1984) Examination of the hand upper limb, Philadelphia: 22
W.B. Saunders. Philadelphia, USA.
23
Design of an autonomous and cooperative robots laboratory
Guillermo González-‐de-‐Rivera, Ricardo Ribalda, Angel de Castro, Javier Garrido
Dept. Ingeniería Informática. Escuela Politécnica Superior. Universidad Autónoma de Madrid. C/ Francisco Tomás y Valiente 11. 28049 Madrid (Spain). {guillermo.gdrivera, ricardo.ribalda, angel.decastro, javier.garrido}@uam.es
Abstract This paper proposes a new hardware/software platform designed for laboratory practices of autonomous robots. The course is offered in both Computer and Telecommunications Engineering, but is flexible enough to be offered in other technical degrees. The open design of the platform allows the students to focus their work either in software or hardware aspects. The offered hardware platform is enough for allowing practices in which only the software is changed, focusing on algorithm design and software tests, using almost any programming language under multiple OS. On the other hand, students can also focus on the hardware design, developing and implementing new peripherals with sensors or hardware controllers, and forgetting about software integration problems. This is possible thanks to a set of easy rules for rapid software integration provided in the platform. Using this new platform a set of new competences are available.
1. Introduction This paper proposes the laboratory practices of a course in robotics offered in the Computer Engineering degree of the Universidad Autonóma de Madrid (Spain). This is an elective course of the last course of the degree. It tries to complement the previously acquired knowledge with some additional formation in control and electronics, offering the possibility to design and implement a HW-‐SW project. In order to show the acceptance among students in Computer Science, Fig. 1 shows the number of students registered in the proposed course in robotics compared to the average number of students registered in the other possible elective courses. Although only students in the last two years can register in elective courses, the percentage is with respect to the total number of students in the Computer Science degree. The proposed course was about 2% below the rest of courses in the first academic years, but has been in the average or even above the average during the last 5 years. We have to take into account that this improvement is in spite of the strong laboratory content in mechatronics and electronics, which are usually not well accepted among Computer Science students. Although the course includes both theoretical and practical contents, the practical part has more weight. The main element of these practices is a new robotics design platform. This platform is the result of a series of research projects developed since 2005. The robotics course started in 1999-‐ 2000. In that first year, students had to develop their own simple control board for the robot. Given the profile of the students, with not much expertise in electronics design, few groups (formed by couples) obtained a complete and working (although simple) robot. In order to solve this problem, the next year a development control board designed ad-‐hoc, 24
GP_Bot (Glez de Rivera et al, 2002), based on a Motorola 8-‐bits microcontroller was used, each group using their own unit.
Fig. 1: Comparative of % of students in elective courses For the initial specification, it was established that the new system should be a flexible, general purpose and low cost one. It should have enough resources for managing the elements of a basic robot, such as motors, infrared sensors, switches, etc. On the other hand, it should have enough processing capability and memory for managing artificial intelligence algorithms, creating maps of its environment, etc. These last objectives should be studied carefully, because if not the design could be much more complex and expensive. The solution was to combine the flexibility, size and low cost of a microcontroller with the processing capabilities of a PC. The link between both elements is a radio module that enables bidirectional communication between both processors. In this way, the PC is in charge of the complex processing tasks, while the microcontroller, which is on-‐board in the robot, manages the motors and sensors. Anyway, the system allows to use the microcontroller in an autonomous way if no complex processing is necessary. Using this platform all the groups obtained a working robot programming the GP_Bot platform and developing different algorithms. During the next years, the designed robots have evolved and the GP_Bot platform was not enough in all cases. Therefore, in 2005-‐06 the proposed platform, GdRBot (Glez de Rivera et al, 2005a; Glez de Rivera et al, 2005b), started to be used. It is quite more complex and ambitious. The GdRBot platform, shown in Fig. 2, consists on a set of generic robots that can be controlled either remotely or locally by a set of heterogeneous devices. Furthermore, it allows adding new sensors or actuators to the robots in a very simple way. The main contribution of the platform is allowing the student to create complex algorithms which can be run in the robot, using any programming language with almost no limitation, in the same way that would be used for programming a simulator.
25
Fig. 2: GdR-‐Bot Platform
2. Platforms description 2.1 GP_Bot platform Basic description The GP_Bot platform is basically formed by two blocks: the control unit (CPU) and the external interfaces, as shown in Fig. 3. The control unit is the Motorola MC68HC908GP32 8-‐bit microcontroller. Its architecture is based on the M68HC08 family, being optimized for C compilers and control applications. It is completely static and includes design options for low power. It can work in Monitor mode, in which the internal resources can be accessed from a PC, including registers and memory (both Flash and RAM) content, and even allowing step-‐by-‐step execution of the stored program, which is very useful for tests and debugging.
Fig. 3: GP_Bot platform A QFP (quad flat pack) package of 44 pins was chosen, allowing a reduced size board (70 x 65 mm) and the maximum number of I/O for the user. The microcontroller is the core of a board with the following characteristics: 26
•
MC68HC908GP32 microcontroller with a crystal at 9.8304 MHz.
•
RS-‐232 driver (MAX232).
•
Radio communications module using the 433 MHz band.
•
Power supply of 5 V.
•
Input for the Monitor cable connected from the PC.
•
External access to all the I/O pins of the microcontroller.
As a complement, an auxiliary board was designed which is an interface between the GP_Bot board and some transducers, such as motors, infrared sensors and switches. It also has some I/O general purpose pins for the designer. The size of this auxiliary board is the same as the GP_Bot, and the connectors are located in the same position, creating a compact and small set with both boards. Its main characteristics are: •
Interface with up to 4 dc motors or 2 step-‐by-‐step motors.
•
Direct connection with 4 infrared sensors, including their polarization.
•
8 analog inputs, which can also be configured as digital I/O.
•
The motors can be powered with voltages different from the digital voltage.
The driver for the motors is based in two L293D chips, while the infrared driver is designed for the connection of 4 CNY70 or equivalent sensors. Each infrared sensor can be read from a digital or analog pin. This allows the system to distinguish between more than two colors. Laboratories contents During the course, a series of laboratory practices are held ranging from the basics of the platform to complex tasks. As an example, the laboratories contents of the 2001/02 academic year are shown: •
Laboratory 1 o First approximation to some basic sensors: polarization, tests and measurements. o GP_Bot board presentation. Compiler and debugging tools. o Interface with the PC. o Design and implementation of a mobile robot. o Simple problem solution.
•
Laboratory 2 o Radio communication between the robot and a PC.
•
Laboratory 3 o Control algorithms design: application to the control of dc motors.
•
Laboratory 4 o Basics of artificial intelligence: application to the creation of a map of the environment.
Acquired competences •
Analysis and interpretation of datasheets. 27
•
Asynchronous serial communication protocol RS-‐232.
•
Implementation of algorithms in real systems.
•
Low complexity control problems solution using embedded systems.
2.2 GdR_Bot platform Basic description The GdRBot platform consists in a series of generic PC-‐based robots and their basic control. These robots can be either controlled remotely or locally by a heterogeneous set of devices. They also allow the easy integration of new sensors or actuators. The main contribution is that the student can develop high level complex algorithms to be executed in the robot, while the basic control software (direct control of motors and sensors) is already part of the offered platform. These algorithms can be developed in almost any programming language, exactly the same as if a simulator were used. Hardware description: the only requirement of the hardware platform is to be able to run Linux. Multiple hardware platforms could be used. However, the students are provided with a working hardware platform, which is shown in Fig. 4a. Its main control device is a VIA EPIA motherboard, model TC10000 at 1 GHz with 512 Mbytes of RAM. This is enough for almost any algorithm the students can develop in a course. The board includes connections via Ethernet, Wifi, Bluetooth, GSM modem, and any Linux supported device can also be added. The list of available sensors in the platform includes a video camera, ultrasonic and infrared detectors, and diverse switches and buttons. Most of the available sensors are controlled in a distributed architecture using GP_Bot boards connected to the GdRBot using a serial protocol (sensor server, Glez de Rivera et al, 2005c). In this way, the central controller and the sensors controllers can be separated: the central controller just sends requests and receives measurements. As a result, any other sensor can be included with the only condition of being compliant with the serial protocol. Regarding actuators, there are two motored wheels and a free wheel. The motored wheels use a step-‐by-‐step motor controlled by a dedicated processor. The complete robot is mounted on an aluminium structure and powered by a 12 V plumb battery. The robot is quite compact, with a total size of 20x30 cm approximately.
a. Based on EPIA
b. Based on XScale Fig. 4: Two different hardware platforms 28
In the last academic year, 2008/09, a new HW design has been incorporated (see Fig. 4b) with the following characteristics: • Device based on the Intel XScale PXA255 Microprocessor • Sensorial servers: GP_Bot platform • Network interfaces: Wireless, Ethernet, USB port, and Serial ports. • Geared DC (Faulhaber 1624E012S model). Motor driver TLE4207G. • Two infrared sensors (Sharp GPD2D12). • Two ultrasound sensors (SRF04). • 6 V battery. Software description: the VIA EPIA motherboard runs Linux, and a web server is mounted on it, which is in charge of receiving actuation or sensing requests via XML-‐RPC. In order to use the robot, any XML-‐RPC compliant system can be used. The platform provided to the students includes a client and server examples. The client sends requests and supervises the servers through XML-‐RPC calls (Glez de Rivera et al, 2009). The server is always installed in the robots, while the client can either be installed in a robot or any other system. Clients installed on robots are used for self-‐management tasks, such as avoiding collisions, and for cooperative tasks. Laboratories contents The laboratories of the course includes 4 practices. A basic schedule is proposed, which includes most elements but not in much depth. Students can choose to change their schedules to get in further depth in some aspects. The basic schedule is as follows: • Practice 0. Introduction to the GdRBot platform. Using a basic robot, students start to control it using high level languages such as Java or C#. The basics of XML-‐RPC calls are studied. • Practice 1. Adding a new sensor using the GP_Bot board. Students add a new sensor using the GP_Bot board as its direct controller. The basics of microcontroller programming are learnt. • Practice 2. Integration of the sensor in the platform. Once the student has controlled a sensor using the GP_Bot, the sensor subsystem is integrated in the robot developing a CGI accessible via web. The student learns how to program XML-‐RPC functions and how to create CGIs. • Practice 3. Cooperative tasks. A task that demands a cooperative behavior is proposed,
forcing the interaction between robots that use the sensors previously integrated. The objective is to make the student realize about the complexity of cooperative algorithms.
Acquired competences •
Analysis and interpretation of datasheets.
•
Criteria for choosing the option that better solves a specific problem. The previous platform had all the necessary components for the laboratories. In the new platform, the student must choose the most appropriate components.
•
Ability to solve problems that appear in the physical implementation that were not considered in the theoretical design. During the physical implementation can appear problems not considered in the theoretical design, such as signal interference, external 29
noise, impedance coupling, etc. The student must be able to solve them. •
Ability to choose between different communication protocols and to use them. In the new platform, students have more communication options (Ethernet, Wifi, Bluetooth, GSM MODEM, ZigBee, etc), so they must choose the best solution for their problem.
•
Implementation of mid-‐complexity algorithms in real systems. The algorithms are not only simulated, but also implemented in physical embedded systems.
•
Ability to solve mid-‐complexity control problems, based on embedded systems and cooperative systems. The new platform has an architecture that allows to solve problems using cooperative systems.
3. Results Since the new platform is being used, the complexity of the laboratory practices has increased, but also the competences acquired by the students. Table 1 shows the number of students registered in the proposed course and the percentage of students that passed it. In spite of the increase in the laboratories complexity, the number of students has kept on growing and the percentage of success remains in satisfactory levels. As it can be seen, the percentage of success was always above 80%. Table 1: Academic success of the course Robotics.
Academic Year Computer Science Eng.
09/00 00/01 01/02 02/03 03/04 04/05 05/06 06/07 07/08
# Students
29
33
39
34
62
93
64
62
72
% Passed
96,6
88,8
92,3
100
87,1
86
100
80,6
84,7
4. Conclusions Using the proposed GdRBot platform, students can learn the theoretical and practical aspects of complex robot tasks. Almost any programming language and OS can be used during the course. Thanks to the new platform, which is complete but open to new additions, the course can be focused either in software or hardware development, or a mixture of both. Regarding the acquired competences for the European Higher Education Area (EHEA), they have been notably improved in comprehension and application aspects with respect to the previous laboratories model. The academic results after changing the platform have not changed significantly in spite of the important increase in the complexity level of the laboratories.
References G. Glez de Rivera, G., López-‐Buedo, S., González, I., Venegas, C., Garrido, J., Boemo, E. (2002). GP_BOT: Plataforma Hardware para la enseñanza de Robótica en Ingeniería Informática. In Tecnologías Aplicadas a la Enseñanza de la Electrónica (TAEE'02). Las Palmas de Gran Canaria, Spain, pp. 67-‐70. Glez. de Rivera, G., Ribalda,R., Colas, J., Garrido, J. (2005a). A Generic Software Platform for Controlling Collaborative Robotic System using XML-‐RPC, In Proceedings of IEEE/ASME International Conference on Advanced Intelligent Mechatronics (AIM 2005). Monterrey (USA), 30
ISBN: 0-‐7803-‐9047-‐4, pp. 1336-‐1341. Glez. de Rivera, G., Ribalda, R., Koroutchev, K., Colas, J., Garrido, J. (2005b). Hardware Independent Architecture for Autonomous Colaborative Agents, In Proceedings of 2nd International Conference on Informatics in Control, Automation & Robotics (ICINCO-‐2005), Barcelona, Spain, pp. 459-‐462. Glez. de Rivera, G., Ribalda, R., Colás, J., Garrido, J. (2005c). Plataforma genérica para desarrollos basados en agentes móviles. Actas de Ubiquitius Computing & Ambient Intelligence (UCAmI-‐05), Granada, Spain, pp. 363-‐369. Glez. de Rivera, G., Ribalda, R., de Castro, A., Garrido, J.(2009). Performance of an open multi-‐ agent remote sensing architecture based on XML-‐RPC in low-‐profile Embedded Systems. Proc. of 7th International Conference on Practical Applications of Agents and Multi-‐Agent Systems (PAAMS’09), Y. Demazeau, J. Pavón, J.M.Corchado, J. Bajo, Advanced in Intelligen& Soft Computing vol 55,Salamanca, Spain, ISBN: 978-‐3-‐642-‐004867-‐2, pp. 520-‐528.
31
Database design using a web-‐based e-‐learning tool Josep Soler (1), Imma Boada (1), Ferran Prados (1), Jordi Poch (1), Ramon Fabregat (2) (1)
Department of Computer Science and Applied Mathematics. University of Girona Campus Montilivi. Edificio P4. 17071 Girona (josep.soler,imma.boada,ferran.prados,[email protected] (2
) Institute of Informatics and Applications. University of Girona Campus Montilivi. Edificio P4. 17071 Girona [email protected]
Abstract ACME-‐DB is a web-‐based e-‐learning tool for skills training and automatic assessment of main database course topics. This tool is composed of a set of correction modules each one designed for a specific type of problems. Among them, entity-‐relationship diagrams, relational database schemas, normalization, relational algebra and SQL. In this paper we describe how ACME-‐DB has been used in teaching/learning of database design in our university and how it has influenced in the academic results.
1. Introduction All the computing disciplines specified by the ACM/IEEE/AIS curricula provide the general guidelines of a database course (http://www.acm.org/education/curricula-‐recommendations) . The issue of how to meet these guidelines is not addressed and different studies have been carried out to analyze the contents covered in the database courses. The majority of educators (Robert et al., 2000; Springsteel et al., 2000; Robert & Ricardo, 2003) agree that they spent the most time of the course on main topics of database development stages, i.e. database design, relational model and Structured Query Language (SQL). These topics are part of the core of computing disciplines and are extensively covered in leading database textbooks (Elmasri & Navathe, 2007; Connoly & Begg, 2005; Date, 2004; Silberschatz, 2005). Despite not being a general consensus in the database course contents the majority of them have as the main objective to introduce students to main database topics and take them through all stages of database development. But, as important as the course contents is the teaching methodology applied by educators. In general, teachers agree that students have to receive a solid background in concepts, introduced in teaching classrooms, as well as practical development of database skills. In this context, web-‐based teaching and learning resources have become fundamental and a valuable tool to complement and support teaching classrooms (blended learning). However, although current e-‐learning tools are able to cover the majority of database course contents, it is difficult to find a unique environment that supports all of them and also the automatic correction of exercises. To overcome this limitation in 2003 we started to develop the ACME-‐DB environment which is part of the ACME1 platform (Soler et al, 2002). ACME-‐DB is a web-‐based e-‐learning tool for skills training and automatic assessment of main database course topics. Its main feature is the automatic correction of database exercises. ACME-‐DB is composed of a set of correction modules each one designed for a specific type of problems. Among them, entity-‐relationship diagrams, relational database schemas, normalization, relational algebra and SQL. Moreover, it provides 1
The acronym ACME stands for the catalan for “Continuous Assessment and Improvement of Skills”
32
support to different teaching requirements such as continuous assessment, student tracking, etc. ACME-‐DB is used in our university as a complement to traditional classroom database courses in Computer Science degrees since the 2004/2005 course. Since then the number of activities has been increased leading to an improvement on the academic results. The goal of this paper is to describe the experience of applying ACME-‐DB in database design of our university and how it has influenced in the academic results. The paper is structured as follows. In Section 2, related work is presented. In Section 3, we present the ACME-‐DB environment. In Section 4, we describe how ACME-‐DB has been used in teaching/learning of database design and we present the obtained results. Finally, in Section 5, conclusions and future work are presented.
2. Related work In this section we give a quick overview of the database design contents and a description of the teaching methodology applied in our university. Afterwards, we briefly review the different e-‐ learning tools described in the literature to support teaching and learning contents in database design. 2.1. Teaching Database design Database design is one of the main topic of any introductory database course. The creation of a database requires a design process to define types, structures and constraints for the data to be stored in the computer. This process can be summarized in four main steps:
First, the analysis of the requirements of the real world situation that has to be represented.
Second, the definition of the conceptual schema that gives a high level description of the database and the requirements that data must satisfy. The most popular approach for conceptual schema designing is the Entity-‐Relationship (ER) model (Chen, 1976). The ER model considers the world as a set of entities and the relationships between them.
Third, the definition of a logical design which gives a high level schema implementable on a database management system. The relational model (Codd, 1970) is the most common data model used for database management. It represents the database as a collection of relations where each relation resembles a table of values. To create relations with no redundant data, with an efficient data organization and that can be modified in a consistent and correct manner, a normalization process is applied.
Fourth, the definition of a physical design which represents the internal data storage details.
When all these concepts are acquired, students have the knowledge required to implement a relational database schema using any one of the available Database Management System (DBMS). 2.2. Database design in our University The methodology applied in the database courses of our university is the following. There are lecture sessions, where the teacher introduces main theory concepts and laboratory sessions where exercises are assigned to the students to put in practice these concepts. These exercises are related with real cases and take student trough the different stages of the design process. To star, the student creates conceptual models for small problems. Once these concepts are acquired 33
more complex exercises are assigned. The next step is devoted to logical design concepts. The student transforms a conceptual model into a logical model targeted to a relational database implementation. Students learn to map a conceptual model into a logical model that can in turn be readily transformed into a relational database schema. At this point, the central concepts of the relational model (domains, keys, integrity constraints, and so on) are engaged. Finally, the database schema is created. The student defines the tables, with the corresponding attributes, primary and foreign keys, etc. A good strategy to acquire database design skills is to solve exercises similar to real-‐world problems. With this purpose different exercises are assigned to the students. The most critical issue is the time required to correct these exercises. Moreover, if we consider that the solutions are not unique. To establish a trade-‐off between the number of exercises and the time required to correct them, we gave to the students a list of exercises and only some of them were corrected in the class. In addition, two of these exercises were assigned to the students as homework and then they were corrected by the teacher. The main drawback of this strategy was that students only solved the assigned problems. Due to the importance of practice in the context of these courses and considering the requirements of the new European Higher Education Area, we decided to integrate e-‐learning tools in the applied methodology in order to overcome the detected limitations. Fortunately, the functionalities of our e-‐learning platform, ACME, satisfy these requirements. In addition, ACME provides support for the course management, student tracking, etc. For all these, we developed the modules needed to support the automatic correction of ER diagrams, relational database schemas and normalization. In this way, we will be able to support in a same environment all the functionalities required to cover the database design needs. This new environment, denoted ACME-‐DB, is described in Section 3. 2.3. Database design Tools In last years a large number of e-‐learning environments that provide and support different teaching and learning topics of database courses have been proposed. In this section, we describe the most representative. To present them we consider three different groups according to the main topics of the database design process: conceptual and logical design and normalization. ER diagram Correction Tools: As it was previously mentioned, the ER model is the most popular approach for conceptual schema designing. Such a model considers the world as a set of entities and the relationships between them. Therefore, an ER diagram tool has to provide an environment able to support the definition and correction of ER diagrams. The system has to be able to interpret the diagram giving the corresponding feedback to the student. Over the last decade several attempts to develop ER problem solving web environments have been made (Constantino-‐Gonzalez & Suthers, 2000; Suraweera & Mitrovic, 2002; Thomas et al., 2007; Batmaz & Hinde, 2007). The most representative is KERMIT proposed by (Suraweera & Mitrovic, 2002). KERMIT is an intelligent tutoring system that contains a set of problems and ideal solutions to them. The system compares the student solutions to the ideal solution using domain knowledge represented in the form of constraints, which are classified into syntactic and semantic ones. Relational Database Schemas Correction Tools: The relational model represents the database as a collection of relations. To define this model the student has to define a set of tables for a given situation of the real world. Therefore, the tool has to provide an environment able to support the definition of tables, with the corresponding attributes, keys and foreign keys and also, the 34
capability to correct and give feedback about correction. It has to be taken into account that the solution of a relational design problem is not unique. Few tools to support and correct logical database design have been proposed. The most representative is ERM-‐Tutor (Milik et al., 2006), a constraint based tutor that teaches logical database design (i.e. mapping conceptual to logical database schemas). Students solve the problem step by step and receive feedback on their solutions. Normalization Tools: The normalization process is applied during the relational model definition to create relations with no redundant data, with an efficient data organization. To teach the normalization process a set of functional, multivalued and join dependencies are given to the student and he has to obtain the corresponding normalized schema. Normalization tools display a relation with the corresponding dependencies, the student propose a normalized schema entering a set of normalized relations and the system has to correct them. Most of existing tools for database normalization have not been conceived as web-‐based environments but as software applications that automate some step of the normalization process. To best of our knowledge there are few web environments that support database normalization learning (Kung & Tung, 2006; Zhang et al., 2005; Mitrovic, 2002). The most representative is NORMIT proposed by Mitrovic. NORMIT is a web-‐enabled tutor for database normalization where the student selects a problem and goes through a number of steps to analyze the quality of the database following a fixed sequence of actions: determine the candidate keys, the closure of a set of attributes and prime attributes; simplify functional dependencies, etc., with a specific web page for each task. Student solutions are analyzed by the system receiving feedback. This environment is a question-‐ answer based approach since student does not propose a solution, he answers if the displayed solution is correct or not. Despite the advantages provided by the described tools with respect to more classical teaching methodologies, they still present several limitations. We consider that one of the main limitations of these tools is that they are specific applications not integrated in a general e-‐learning platform. Hence, they do not support lecturer tasks, such as continuous assessment, tracking of students work to detect weak points, features to obtain statistics of common errors, number of attempts required to solve a problem, etc. For a lecturer all these features are very important since they provide information of student progress and also which topics need further work. On the other hand, another common limitation of the majority of tools is that they do not support automatic correction and only provide a way to show the results of a given exercise for a predefined database. The student has to compare the obtained result with the correct solution. Such an approach is difficult to apply when more than one solution per exercise is possible. Besides the functionalities of a common e-‐learning platform we consider that an e-‐learning environment has to support automatic correction of problems. The capability to automatically generate and correct different exercises allows giving personalized attention to each student. With this idea we conceived the ACME platform.
3. The ACME-‐DB environment In 1998, we started to develop ACME an e-‐learning platform to improve both teaching and learning at the technical/engineering degree programs of our university (Soler et al., 2002). The platform was conceived to integrate new types of problems with minimal modifications. The ACME-‐DB environment is an extension of the ACME tool designed to support in a unique environment the main topics of a database course. We started to develop ACME-‐DB in 2003 with the development of the relational database schemas module (Prados et al., 2005). Since then, entity-‐relationship diagrams (Prados et al., 2006), normalization (Soler et al., 2006), SQL and 35
relational algebra (Soler et al., 2007) correctors have been developed and integrated in the environment. In the following we only consider entity-‐relationship diagrams, relational database schemas and normalization correctors. All these modules apply the same methodology which is briefly described below.
ACME-‐DB has a repository with the problems entered by the teacher. Each problem consists of a descriptor and the procedures required for its automatic correction. In the case of ER diagrams, relational database schemas and normalization problems, due to its complexity, all the possible solutions are entered. ACME-‐DB provides a text editor to enter the problems.
The student enters in the ACME-‐DB environment and once in the system a list with the exercises that compose their workbook appears. This information is presented in a tabular form as it is illustrated in the example of Fig. 1(a). In this example the workbook contains five topics, labeled in the first column of the displayed table from 1 to 5. For each topic, as it can be seen in the second column of the table, there is a different number of exercises. Each row of the table displays the topic, the number of exercise, if it has been solved or not and the number of send solutions. The exercises of the workbook have been assigned automatically by following the teacher specifications and by using the problems stored in the repository of the system.
The student selects one of the exercises of his workbook and proposes a solution. In Fig. 1(b) an example of a problem descriptor is given. To enter the solution, there is a specific interface which is specifically designed for each type of problem. In Fig. 2 we illustrate the interfaces corresponding to ER diagrams and relational database schemas. The ER interface (Fig. 2(a)) integrates different designing tools to create an ER diagram. The different parts of the interface are: (a) buttons to draw the elements of the ER-‐diagram, when a button is pressed its corresponding glyph graphic is drawn in the working area, a rectangle for entities, a diamond for relationships, with two lines connecting the two entities previously selected; (b) working area; (c) menus for input attributes; (d) zoom and (e) correction button. The interface for relational database schemas problems is represented in Fig. 2(b). To design a relational database schema the student defines the tables and the different attributes that compose them. These tables are represented in the screen. Each time the student press the Add button of this interface the information of the items appears in the corresponding table. The normalization interface is similar to the one of Fig. 2 (b).
36
(a)
(b)
Fig. 1: (a) Workbook interface and (b) Problem descriptor
The solution entered by the student is send to the corresponding corrector and the correction process is done automatically. In our case, the correction strategy is based on a matching process that compares the student solution with each one stored in the repository. If no matching is found, the most similar solution is selected and is used to return feedback. These feedback messages are designed according to the type of problem, and in case of errors return some help to obtain the correct solution. For instance, “More entities are required”, “There are incorrect relation-‐ships”, etc.
For each student the system records all the entered solutions. This information is used to grade the exercises. The grading process uses a function specifically designed for each type of problem where different parameters are taken into account. For instance, in the ER diagrams we consider the number of correct/incorrect entities/relationships/attributes, the number of attempts before a correct solution is obtained, etc. The marks of all the problems are used for continuous assessment.
(a)
(b)
Fig. 2: Interfaces for entering solutions (a) ER diagrams and (b) relational database schemas 37
4. Results The different modules were designed, implemented and then tested on an experimental database course 2004/05. We evaluate the modules independently, obtaining very promising results. In this section, we describe how the ACME-‐DB environment has been used in database design and the obtained results. Due to the bad results achieved with the previous methodology (see Section 2.2) we decided to modify it introducing the ACME-‐DB platform. The idea was to introduce this tool to improve database design skills acquisition. We applied a new teaching/learning methodology where ACME-‐ DB has a main role. The goal was exploit all the capabilities of the platform to assign, solve and automatically correct the activities assigned to the students. The system creates a different workbook for each student containing exercises of the main topics: ER-‐diagrams, relational database schemas and normalization. For each topic we define exercises of different complexity according to the number of entities or relations. The easier exercises range from 5 to 10 entities/relations while the more difficult from 15 to 20. These exercises are used for continuous assessment contributing in a 50% on the final mark and the resting 50% is obtained from an exam done at the end of each topic. The continuous assessment mark is obtained automatically taking into account student work: the number and type of errors, the number of solutions before the correct one is obtained, etc. The capability to automatically obtain this mark reduces the time required to correct exercises allowing teacher to spent time in other tasks. To control students work the teacher tracks their solution and according to detected errors he can propose additional tasks in order to improve the learning process. In Table 1, we collect the results obtained using the platform in the last four years. For each one of the three topics (ER-‐diagrams, relational database schemas and normalization), we give the number of students, the number of assigned problems, the % of students that have read the problems, have sent solutions, have sent correct solutions and also the % of students that have solved the problems at the first, the second, the third and with more than three attempts. Note that more than 80% of students read the exercises and more than 70% solve them correctly. The number of students that obtain the correct solution at the first or second attempt is between 63% and 80%, and the rest requires three or more attempts. Table 1. Information obtained from the ACME-‐DB tool with respect to its use.
To evaluate the impact on the academic results we compare the results obtained before the application of ACME-‐DB with the results obtained in these last four years. This data is collected in Table 2. For each course we give the number of students and also their final marks graded from A to D, where A corresponds to the best mark and D the worst. The NP column represents the students that have not assisted to the course. Finally, in the two last columns we give the % students that have passed and not the course, respectively. Note that the results obtained when 38
using ACME-‐DB (2005/06 to 2008/09) are better than when no using the platform. Moreover, if we analyze the number of students that have passed the course there is a considerable increment compared with the results obtained when no using the platform. We consider that these better results are due to the fact that the student feels supported all the time. He knows that when he has a solution he can obtain the automatic correction at any moment. Table 2. Academic results no using and using (grey background rows) the ACME-‐DB environment
Finally, in Table 3 we evaluate the relationship between the number of students that have solved the ACME-‐DB exercises and the number of student that have passed the course. We group students in three different rows according to the exercises that have solved correctly. In the first row students that have solved less than 50%, in the second between 50% and 75% and in the last row more than 75%. For each group of students and for each course, we give the % of students and the % of students from this group that has passed the course. Note that when students solve correctly less than 50% of exercises the possibility of passing the course is minimal. On the contrary when they solve more than 75% of exercises the number of students that pass is greater than 80%. Table 3. Relationship between the number of students that have solved the ACME-‐DB exercises and the number of students that have passed the course
Despite the advantages provided by the ACME-‐DB environment, it has to be taken into account that this new methodology requires an extra work in order to prepare exercises for the students. The main advantage is that these exercises are stored in the repository of the system and can be used in different courses. In general, teachers consider that the application of the ACME-‐DB has improved their teaching methodology and this is reflected in the final marks.
5. Conclusions We have presented ACME-‐DB a web based environment to support teaching and learning of database design. We have described the main modules that integrate this environment and how it has been applied in a database course of our university. Data collected during four years of application showed how academic results have been improved. Our future work will be centered on a more exhaustive analysis of collected data. We also plan to develop the module that supports the automatic correction of conceptual object modeling using UML class diagrams. 39
References Batmaz, F. and Hinde, C.J. (2007). A web-‐based Semi-‐automatic Assessment of Conceptual Database Diagrams, In Proceedings of the 6th Web-‐Based Education WBE 07, Chamonix, France, 427-‐432. Chen, P. (1976). The entity-‐Relationship model. Towards a Unified View of Data, ACM Transactions on Database Systems, 1, 9-‐36. Codd, E.F. (1970). A relational Model of Data for Large Shared Data Banks, Communications of the ACM, 13, 377-‐387. Connoly, T. and Begg, C. (2005). Database Systems: A Practical Approach to Design, Implementation and Management, 4th Edition Addisson Wesley. Constantino-‐Gonzalez, M. and Suthers, D.D. (2000). A coached collaborative learning environment for entity relationship modelling. In Proceedings of 5th International Conference Intelligent Tutoring System ITS 2000. Montreal, Canada, 324-‐333. Date C.J. (2004). An Introduction to Database Systems, 8th Edition Addisson Wesley. Elmasri, R. and Navathe, B. (2007). Fundamentals of Database Systems, 5th Edition Addison Wesley. Kung, H. and Tung, H. (2006). A Web-‐based Tool to enhance Teaching/Learning Database Normalization, In Proceedings of 2006 Southern Association for Information System Conference, Jacksonville, USA. 251-‐258. Milik, N., Marshall, M. and Mitrovic, A. (2006). Teaching Logical Database Design in ERM-‐Tutor. In Proceedings of 8th International Conference Intelligent Tutoring System ITS 2006, Jhongli, Taiwan. LNCS 4053, 707-‐709. Mitrovic, A. (2002). Normit: a web-‐enabled tutor for database normalization, In Proceedings of International Conference on Computers in Education ICCE, Auckland, New Zeland, 1276-‐1280. Prados, F., Boada, I., Soler, J. and Poch, J. (2005). An Automatic Correction Tool for relational Database Schemas, In Proceedings of International Conference on Information Technology based higher Education and Training ITHET05, Santo Domingo, Dominican Republic, S3C 9-‐ 14. Prados, F., Boada, I., Soler, J. and Poch, J. (2006). A web based-‐tool for Entity-‐Relationship Modeling, In Proceedings of International Conference on Computational Science and its Applications ICCSA 2006, Glasgow, UK, LNCS 3980, 364-‐372. Robbert, M.A., Wang, M., Guimaraes, M. and Myers, M.E. (2000). The Database Course: What must be taught, ACM SIGCSE Bulletin, 32, 403-‐404. Robbert, M.A. and Ricardo, C.M. (2003). Trends in the evolution of the Database Curriculum, ACM SIGCSE Bulletin, 35, 139-‐143. Silberschatz, A., Korth, H. and Sudarshan, S. (2005). Database System Concepts, 5th Edition McGraw Hill. Springsteel, F., Robbert, M.A. and Ricardo, C.M. (2000). The next Decade of the Database Course: Three Decades speak to the next, ACM SIGCSE Bulleti, 32, 41-‐45. Soler, J., Poch, J., Barrabes, E., Juher, D. and Ripoll, J. (2002). A tool for the continuous assessment and improvement of the student’s skills in a mathematics course, In Proceedings of International Symposium of Technology of Information and Communication in Education for 40
engineering and industry TICE 2002, Lyon, France, 105-‐110. Soler, J., Boada, I., Prados, F. and Poch, J. (2006). A web-‐based Problem-‐Solving Environment for database Normalization, In Proceedings of 8th International Symposium on Computers in Education SIIE 2006, León, Spain. Soler, J., Boada, I., Prados, F. and Poch, J. (2007). An automatic correction tool for relational Algebra Queries. In Proceedings of International Conference on Computational Science and its Applications ICCSA 2007, Kuala Lumpur, Malaysia, LNCS 4706, 861-‐872. Suraweera, P. and Mitrovic, A. (2002). KERMIT: A Constraint-‐Based Tutor for Database Modeling, In Proceedings of International Conference Intelligent Tutoring System ITS 2002, Biarritz, France, LNCS 2363, 377-‐387. Thomas, P., Waugh, K. and Smith, N. (2007). Tools for supporting the teaching and learning of data modeling, In Proceedings of World Conference on Educational Multimedia, Hypermedia and Telecommunications EDMEDIA 2007. Vancouver, Canada, 4014-‐4023. Zhang, L., Kaschek, R. and Kinshuk (2005). Developing a Knowledge Management Support Systems for Teaching Database Normalization. In Proceedings of 5th International Conference on Advanced Learning Technologies ICALT 2005, Kaohsiung, Taiwan, 344-‐348.
41
The cost of learning and teaching Java in the Bologna process Camino Fernández (1), David Díez (2), Jorge Torres (3), Telmo Zarraonandia (2) (1)
Universidad de León. Escuela de Ingenierías Industrial e Informática. Campus de Vegazana, 28071-‐León [email protected] (2)
Universidad Carlos III de Madrid. Departamento de Informática. Escuela Politécnica Superior. Avda. de la Universidad, 30 – 28911 Leganés (Madrid) {david.diez,telmoagustin.zarraonandia}@uc3m.es (3)
Tecnológico de Monterrey. Campus Querétaro. Epigmenio González No 500, Fracc. San Pablo, Querétaro, Qro CP 76130 (México) [email protected]
Abstract The European Higher Education Area (EHEA) involved in the Bologna process tries to change both the academic organization and the way teaching is implemented at University. Regarding the way of teaching, an instructional strategy focused on teaching will be replaced by methodologies focused on students learning. This paper shows the pilot case study of an introductory programming course in Java of the degree in Computer Engineering performed to estimate the resources needed to start up with these new methodoligies. During a complete semester, students followed a continuous assessment process that involved an extra effort for both students and teachers. The results show that students were benefitted by the experience, but university is not really prepared to support the whole process with its actual parameters. Keywords: EHEA, Bologna Process, introductory programming course, Java lenguage, case study.
1. Introduction The overarching aim of the Bologna Process is to create the European Higher Educational Area (EHEA) by making academic degree and quality assurance standards more comparable and compatible throughout Europe (Bologna, 1999). The EHEA claims not only a homogenous academy system that facilitates mobility of students, graduates and higher education staff around Europe, but also education plans and methodologies focused on students learning. In this context, new instructional strategies and redesigned courses are needed. With the purpose of making straightforward this process of change, different innovation projects have been performed. In particular, Universidad Carlos III de Madrid performed a pilot case study in the first year of the degree in Computer Engineering. This pilot case study aimed at simulating the EHEA context in order to identify further needs and to assess their cost. Our experience in an introductory programming course of such a pilot has disclosed both positive and negative issues. On one hand, the results of the course have been improved if compared to the previous ones, and students have considered the course structure very positive. On the other hand, dedication of teacher, coordination activities, as well as instructional resources should be actually increased to achieve the goals established. The rest of the paper is organized as follows. The description of the pilot case study, its goals and context, are described in section 2. Section 3 briefly explains the most relevant outcomes of our pilot case study. Finally, conclusions and a set of recommendations and ideas for further discussion are compiled in the last section. 42
2. Description of the pilot case The pilot project was conceived by the university three years before the first new grade was introduced. The objective of these pilot courses was both estimating the resources needed to start up with the new grades, and also knowing the students response to the new learning and teaching methodologies. Having presented the problem that motivated our work, the following subsections explain the learning context in which our introductory programming course was deployed. 2.1. Instructional Strategy Teachers involved in the pilot case were trained on how Bologna should be implemented. According to experts consulted for this project, three main concerns should be considered:
The main point was that everything that implies an effort for students should be measured. Thus, active learning activities as asking questions, proposing new themes or answering teacher’s proposals would be considered as a small part of the final mark.
Students’ feedback should be continuous. Futhermore, the result of that assessment should be returned to the students as soon as possible. Feedback helps to correct the errors and to have a better appreciation of the deficiencies that should be overcome.
Monitoring activities might observe the evolution of the subject. The final objective is that teachers identify knowledge gaps among students in order to have a better understanding of potential corrective activities.
2.2. Course Methodology The course is taught in the first semester of the year of the degree in Computer Engineering. The course lasts for fifteen (15) weeks with a total of five (5) teaching hours per weeks – including theory and laboratory work -‐. The course is coordinated by one teacher and it is taught by eight teachers, with an extra help of another two teachers for the first year. The first year 141 students, and the second year 122, split into three groups, took the course. A common approach in programming education is first to teach the basics of a programming language and then guide students towards effective strategies for the whole programming process (Robins et. al, 2003). Usually, introductory programming courses are focused on teaching about a particular programming language (Lahtinen et. al, 2005). In our case, the course focuses on the object oriented programming paradigm and includes a set of basic programming concepts, such as data types, control sequences and character chains, as well as basic knowledge on algorithms. Java is used as the reference programming language. The course includes lectures and laboratory work. Laboratory work is made up of several programming exercises. Such exercises should be resolved in groups of two students. Programming exercises are handed in at regular intervals throughout the course. The final grade is obtained by combining the results obtained in theoretical examinations (sixty percent of the final grade) with those from practical laboratory sessions (forty percent of the final grade). 2.3. Assessment Process The course included seven (7) multiple-‐choice exams and eleven (11) practical exercises distributed in the fifteen (15) weeks of the course. Both types of assessments were included in the continuous evaluation. At the end of the semester, students took their final written exam and also implemented a small application in java (1000-‐2000 code lines). As we said before, activ class participation contributed to the final mark also, but this contribution is considered only for those 43
students that pass the tests and the laboratory work.
3. Results According to the pilot project’s objetives, two main issues should be analyzed: (i) academic results; and (ii) human resources needs. With the purpose of identifying pros and cons, we have considered data to the same introductory programming course for seven years. The last two ones correspond to the pilot project. Regarding the academic results, as shown in Fig. 1, a different situation can be observed before and after the pilot project. Before the pilot project a high rate of students usually took the first exam but only a low rate passed that first exam. The explanation for those results is that students were facing their first exams at university and they were used to taking all the exams, like they had done in previous studies, although they were not properly prepared for them. The situation in the second chance, September exam, was quite different: The rate of students taking the exam is quite lower, but the rate of students that pass it is much higher. Our experience shows that in this second chance, only the students that are really prepared take the exam. After the pilot project everything changes. In the first exam we have slightly more students, but from those students a much higher rate pass the exam, in fact, in graph a) the trend has swapped. In the second exam there is also a higher rate of students taking the exam, but the number of students that pass it has decreased significantly. This change in the trends shows that continuous evaluation can be an important tool to adapt the course to the students needs and obtain better results.
Fig. 1: Academic results Regarding human resources needs, Fig. 2 shows the total amount of hours dedicated to this pilot project by every one of the ten teachers involved in it. The total amount of time traditionally assigned to teachers was doubled by the estimated time assigned for the pilot project. However, 44
real data collected shows that the final amount of time was even increased in more than a thirty per cent. The most important increase was related to coordinating (teacher 3) and monitoring activities (teachers 7 and 8). Mandatory tutorships were included in order to know students´ needs and opinions; thus, two more teachers were joined to help with these activities.
Fig. 2: Human resources
4. Conclusions The main lesson to be learned from this pilot case is that pilot cases are themselves crucial in situations like this one, where a whole process changes, and this change involves a variety of stakeholders. The main features of that change as, for instance, moving the attention to student’s effort or emphasizing the assessment process, were clear from the beginning. Nevertheless, the big amount of small but essential practical details which can make a new initiative fail or success are not shown until a real case starts up. Although reduced groups were one of the main issues in the Bologna process, one of the direct applications of the pilot cases is reducing the groups to a maximum of 20 students. This apparent advantage implies extra work for the course coordinator. These kind of introductory courses usually have between 150 and 200 students and many teachers have to be coordinated for offering a homogeneous course. The key to face the Bologna process implementation successfully is to provide teachers with the tools needed to simplify the process. Not only tools to facilitate coordination among teachers are needed. Effective tools to improve the whole assessment process are even more important, for instance, communication tools that automate the informative feedback of every assignenment (Diez et. al, 2008) because this task has proved to be the most time consuming one.
References Bologna Declaration (1999). Joint declaration of the European Ministers of Education. Retrieved Febrery 20, 2009 from http://www.ond.vlaanderen.be/hogeronderwijs/bologna/documents/MDC/BOLOGNA_DECLARATION1.pdf
Diez, D., Diaz, P., Aedo, I. and Fernandez, C. (2008). DEI-‐CHECK. Automating the assessment process to improve the informative feedback. In Proceedings of the 38th Annual Frontiers in Education Conference, Saratoga Spring, USA.
45
Lahtinen, E., Mutka, K.A. and Järvine, K.M. (2005). A Study of the Difficulties of Novice Programmers. In Proceedings of the 10th Annual Conference on Innovation and Technology in Computer Science Education, Monte de Caparica, Portugal. Robins, A., Rountree, J. and Rountree, N. (2003). Learning and Teaching Programming: A Review and Discussion. Journal of Computer Science Education, volume 13(2), pp. 137-‐172.
46
A High School Educational Platform based on Virtual Worlds Mariano Rico (1), David Camacho (1), Xavier Alaman(1), Estrella Pulido (1) (1)
Escuela Politécnica de la Universidad Autónoma de Madrid Ciudad Universitaria de Cantoblanco Calle Francisco Tomás y Valiente, 11 28049 – Madrid, Spain {Mariano.Rico, David.Camacho, Xavier.Alaman, Estrella.Pulido}@uam.es
Abstract Virtual Worlds, through their three-‐dimensional or two-‐dimensional graphical environments, have become a very popular kind of software application that has been used in different fields, from games to simulation or education. They allow individuals to interact with others through their avatars and with objects in the environment. Virtual Worlds provide new education opportunities where collaboration and cooperation among users can be easily achieved. This paper presents an innovative educational approach that can be applied to different educational areas, and levels, from basic to higher. Initially it has been oriented to teach computer science to high-‐school students. The paper analyses how the current virtual world platforms should be modified so that they can be used in education. It also describes the main issues and problems that need to be solved in order to develop an operative educational platform for undergraduate students. Finally, a usability evaluation study of several existing technologies (3D virtual world platforms, development programming environments, etc.) performed by several (high school) students is presented.
1. Introduction Although Virtual Worlds (VW) have been used in different domains such as Economy (Sinrod, 2007), Social or E-‐Commerce (Talbot, 2008), the most popular are related to massively-‐ multiplayer online games2. However, VWs can be used as a new powerful instrument for instruction and education allowing social interactions, which can be a basis for collaborative education. The attractive 3D graphical environments provided by these VW can be used to improve interaction and a sense of realism. Different initiatives aimed at applying VW to learning, or educational, processes exist. For example, the work of (Baker, Wentz, & Woods, 2009) shows how psychology instructors can use Second Life as a meeting space with students, and to create labs, buildings, and objects that can be used to learn psychology contents and skills. (Cunha, Raposo, & Fuks, 2008) use Second Life as an environment for collaborative learning and generating of new educational contents. The creation of an environment and a location for collaborative learning in Second Life was the focus of the work of (De Lucia, Francese, Passero, & Tortora, 2008), in which objects have been modeled and programmed to support the synchronous role-‐based collaborative activities required by the jigsaw learning technique in a 3D virtual meeting setting. In the specific context of teaching technical subjects, Second Life has been used with medical and health librarians and educators (Boulos, Hetherington, & Wheeler, 2007), in order to explore the pedagogical potentials of Second Life as well as some issues and challenges related to the use of virtual worlds. The recent work of (Bourke, 2009) analyzes how multiple remote participants can engage in 3D geometry within a virtual environment. 2
http://en.wikipedia.org/wiki/List_of_MMOGs
47
This paper presents an innovative educational platform, named VLEAF (Virtual LEArning platForm), which has been designed to stimulate interest and learning ability of students through the use of technologies that are familiar and particularly attractive to them. It also facilitates the implementation of collaborative (students sharing knowledge on a particular topic) and cooperative (students perform a task or solve all together a common problem) teaching techniques. By using the VLEAF platform, the learning model goes from one in which students have an almost passive role (apart from a minimal interaction) and learns on their own, to one where students play the leading role in the learning environment and work with other students and teachers in the creation of knowledge that can be shared with others. Our approach uses a particular Virtual World, named OpenSim that has been recently developed by IBM and is compatible with Second Life, as the base element to implement the new educational platform. The initial goal of this work is to develop a teaching community where students can acquire basic skills related to computer programming. For this reason, an introductory programming course oriented to high school students is designed to analyze how VWs could be adapted and what other elements, such as web portals, documentation or multimedia support are needed to provide the necessary access to both educators and students.
Fig 1. VLEAF platform
2. An educational platform based on VW When teenagers want to use this kind of domains there are some resources that need to be provided. The VLEAF platform is composed of the following elements: -‐
Web portal that allows: fast access to any documentation; student management (two 48
different roles: administrator and educators); access to multimedia information -‐
Data Bases that are used to store: technical and user guides; educational documentation (courses guides, multimedia, etc..); teacher and student profiles; student educational material; Data mining information (logs, conversations, student and educator interaction in the VW, …)
-‐
Other software programs: data mining and statistical software
-‐
VW grid, that provides: physical spaces where the lecture or laboratory can take place; physical spaces to store the educational objects created by teachers and students.
Fig. 1 shows a graphical representation of the platform. The Web portal3 provides educators or students access to technical and educational material. The VLEAF platform has been built on a grid over OpenSim, based on our previous experience in Second Life (SL), this new grid has been designed to allow restricted access educational spaces for high school institutions. Our first campus4, still available at SL and deployed past 2008, is located at the European University, an SL island where there are currently about 20 universities. OpenSim provides an open fully compatible with SL simulation 3D environment that solves the previously mentioned problems. We can define as much space as we need for educators (it is free, so there is no cost associated to the educational task), the information can be stored in locally owned servers, so that it can be analyzed later by educators, and the control over all this world is in the educator hands.
3. A basic programming course in VLEAF Although some important elements of our platform are still under construction (especially those related to the automatic restricted access for high school students), both virtual worlds (at SL and OpenSim) are enough deployed to allow controlled experiments. This section provides a simple case study to test some of the functionalities of our platform. We have designed a programming course to show how a scripting language (the Linden Scripting Language) works. This course has been tested with several high school students, to find out what kind of facilities need to be provided for future experiences with other educational institutions, and students. Initially a basic programming course has been designed to evaluate the potential interest of students in learning these basics by using the VW technologies (Heaton, 2008). This course provides the basics about working in the OpenSim VW and about algorithm programming, and it has been designed as follows: 1. (1 h) Introduction to VW: installation, avatar creation, and brief introduction to VW 2. (1 h) Basics of building: basic introduction to building and creating prims and linking them to form objects. Rotation, position, and other more advanced attributes of prims are studied 3. (1h) Introduction to LSL: syntax and basics of the Linden Scripting Language. Compiling and debugging a script in the VW; how to create scripts and perform basic operations; script structure 4. (1h) Data and variables in LSL: basic data types and variables in LSL; programming script examples 5. (1h) Control structures: how to control scripts through variable values, conditional sentences, 3 4
http://www.ii.uam.es/~dcamacho/vleaf http://www.ii.uam.es/esp/sl/ index.html
49
and the three different loop types available in Second Life 6. (1h) Strings in LSL: comparing and parsing strings in LSL; programming script examples 7. (1h) Objects and Events: sending instant messages; introduction to event-‐based programming 8. (1h) Advanced Data types & Algorithms; lists in LSL to hold a collection of items; searching and sorting algorithms For each session several usability parameters have been measured, to analyze how attractive and useful this environment is for learning basic programming concepts. The questionnaire details and the experimental setup and results can be found in section 4. 3.1. High-‐School educational processes in VLEaF When the potential users of an educational environment similar to the one described in the previous section are teenagers, special care must be taken in order to avoid harassment or any other kind of possible attacks to this kind of users. For this reason, although VLEAF can use our current campus at SecondLife, access to the VLEAF educational platform will only be allowed through our grid at OpenSim. In this grid we can control at any moment the avatars connected and the actions that they could be doing (these actions are saved through the vamp server as data logs). The platform needs to provide the following roles to different users: -‐
Administrator. S/he can control any avatar within the platform (it can only be applied over the grid deployed under OpenSim VW)
-‐
Educators. They will have the control over their student team . They will control (through the logs stored related to their students) and can prevent a connection for a particular student or students. They will manage the educational materials (in traditional formats and in the format of educational virtual objects) available through the web portal and the Virtual World.
-‐
Students. They can access different educational documents through the web portal, and solve exercises proposed by educators through the Virtual World.
Currently the control over high school students are made by a peer-‐to-‐peer process where the administrator of the system provides a set of predefined avatars (including names and passwords) to the responsible educators. Student and Educator interactions in the VW are saved by using the Vamp Server which allows its analysis.
4. Usability evaluation of VLEaF platform This section describes the usability and user satisfaction parameters measured with their related tests, and the practical conclusions achieved. In this evaluation two selected sets of four educators and (high school) students were used to test the platform and to obtain the usability (based on user’s skills), the user satisfaction, and the potential of this platform applied over educational processes. To obtain the user’s skills, we calculate the sum of the numerical values freely auto-‐assigned by each user depending on his/her level of competence on the client side issues described in the questionnaire. The usability of VLEAF was measured by means of a popular standard test called “Practical Heuristics for Usability Evaluation” (Perlman, 1997). This test includes 13 questions ranging from 1 (bad) to 5 (good), which provides a useful measure of the user’s perceived usability. The results of this test are shown in left part of Fig. 2. This figure shows that three types of users can be identified: those with basic skills (range 0-‐20), medium (20-‐40), and advanced 50
(greater than 40). The first two groups are associated to students, divided in basic and advanced. The third group is associated to teachers, with higher experience and skills. The figure shows high usability values for the whole range of participants, although as one might expect, the most skilled users assign slightly lower usability values. A possible explanation is that skilled users are more demanding, and these results in slightly lower evaluations, but even these advanced users provide high usability values. The standard deviation in each range is low for basic students (0.2) and teachers (0.3), denoting a uniform knowledge, but increases for advanced students (0.5). This denotes slightly variations in usability for this range of users, but within reasonable values.
Fig. 2. Left: Usability of VLeaF for different user skills. Right: User’s satisfaction on the user interface as a function of the user skills. The user’s satisfaction concerning the VLEAF user interface, was measured by means of a slightly modified version of the standard test “User Interface Satisfaction” (Chin, Diehl, & Norman, 1988). The standard version includes 27 questions, but it was reduced to 25 due to overlaps with the usability test described previously. Valid responses to these questions were positive integers ranging from 0 (not satisfied at all) to 7 (completely satisfied). It must be noted the different scale value compared to usability range. The results, showing the dependency between the user’s satisfaction and his/her skills are shown in the right part of Fig. 2. The average value for user satisfaction was 5.5, and It is worth noting that the user satisfaction depends on the user skills in the same way that usability, that is, higher-‐skilled users assign a slightly lower value to satisfaction. Three ranges can be identified as it was for usability (the first two for basic and advanced students, and the third one for teachers), and the behavior of the standard deviation for each range follows the same that usability, that is, small deviations for basic students (0.4) and teachers (0.3), and bigger (0.7) deviations for advanced students. From experimental results we can conclude that VLEAF provides good average values for usability and user satisfaction concerning the user interface for a wide range of user competencies, what confirms that VLEAF is a highly usable platform for users in a wide range of skills, from non initiated ones (students) to advanced ones (teachers).
5. Conclusions According to the report on the implementation and use of ICT in schools for primary and secondary education (year 2005-‐2006) under the Plan Avanza5, the 71% of Spanish teachers never 5
http://www.oei.es/tic/TICCD.pdf
51
use a computer to support explanations at their lectures, and 82.2% do not use ICT for presentations or simulations, although the 94.6% stated to have access to computers at their school, and many of them admit that ICTs have a great educational potential. These data demonstrate that new resources are not generally used in primary and secondary education. The reason could be related to the need of an operative infrastructure and tools, services and contents to facilitate their lectures. The use of the proposed platform would solve this problem as it allows educational resources developed by individual students or teachers to be used by others. From our initial empirical evaluation, we have observed that the Virtual World provides a very attractive domain where students discover that learning can be an interesting experience. Although there exist a huge amount of information in Internet related to Virtual Worlds (such as Second Life or OpenSim) or to programming, there is no specific documentation oriented to high-‐school students. Finally, the proposed programming course (based on a simple introduction to C-‐style scripting languages such as LSL) is definitively more interesting than the traditional ones.
Acknowledgments This work has been funded by the Spanish Ministry of Science and Innovation under the projects VLEAF (TIN2008-‐02729-‐E/TIN) and HADA (TIN2007-‐64718). We would like to thank the VLEAF developer team, and students from I.E.S. Antonio de Nebrija for their cooperation in this work.
References Baker, S. C., Wentz, R. K., & Woods, M. M. (2009). Using Virtual Worlds in Education: Second Life as an Educational Tool. Teaching of Psychology, 36(1), 59-‐-‐64. Boulos, M. N. K., Hetherington, L., & Wheeler, S. (2007). Second Life: an overview of the potential of 3-‐D virtual worlds in medical and health education. Health Information and Libraries Journal, 24(4), 233-‐245. Bourke, P. (2009). Evaluating Second Life for the collaborative exploration of 3D fractals. Computer & Graphics -‐UK, 33(1), 113-‐117. Cunha, M., Raposo, A., & Fuks, H. (2008). Educational technology for collaborative virtual environments. Proceedings of the 12nd International Conference on Computer Supported Cooperative Work in Design. Chin, J. P., Diehl, V. A., & Norman, K. L. (1988). Development of an Instrument Measuring User Satisfaction of the Human-‐Computer Interface. Proceedings of ACM CHI'88 Conference on Human Factors in Computing Systems. De Lucia, A., Francese, R., Passero, I., & Tortora, G. (2008). Supporting jigsaw-‐based collaborative learning in Second Life. Proceedings of the 8th IEEE International Conference on Advanced Learning Technologies. Perlman, G. (1997). Practical usability evaluation. Proceedings of the CHI '97: CHI '97 extended abstracts on Human factors in computing systems. Sinrod, E. J. (2007). Virtual world litigation for real. Available on line at http://news.cnet.com/Virtual-‐world-‐litigation-‐for-‐real/2010-‐1047_3-‐6190583.html. Talbot, D. (2008). The fleecing of the avatars. Technology Review -‐Manchester NH-‐, 111(1), 58.
52
Comparing a fully online course to a blended one: the case of compilers Salvador Sánchez Alonso (1), Daniel Rodriguez García (1), Robert Clarisó Viladrosa (2) (1)
Information Engineering research unit, Universidad de Alcala Ctra. de Barcelona, Km. 33.6, 28817 Alcalá de Henares, Spain {salvador.sanchez,daniel.rodriguezg}@uah.es (2)
IT, Multimedia and Telecommunications Department, Universitat Oberta de Catalunya Rambla del Poblenou 156, 08018 Barcelona, Spain [email protected]
Abstract The compilers course is part of the degree in Computer Science that the Open University of Catalonia (UOC) –an online university located in Barcelona– currently offers in fully online mode. In the University of Alcala (UAH), located in Madrid, the same course is given in a traditional, face-‐to-‐face format. Based on the experience of the teachers of these courses during the 2008 academic year, this paper reports on a study carried out to determine whether students at UOC, who take only online courses perform (and consequently learn) as much as students taking identical course in a traditional university (UAH). Preliminary results comparing their marks in the first assessment of the course indicate that the amount of learning is similar in both settings.
1. Introduction The Open University of Catalonia (UOC) is a virtual university aimed at complementing the Catalan university system “by making university studies available to citizens who cannot enroll for a face-‐ to-‐face university degree” (Borges, 1998). As teachers in a traditional (so to speak) university, the University of Alcala, we were curious about how different our UOC students would perform compared to our UAH students. After reading on a similar experience by Anstine & Skidmore (2005), we were interested in establishing whether our UOC students, taking a fully online course, were learning as much as our regular students at UAH, even if the latter had unlimited access to teachers, as they could arrange an appointment anytime to meet with a teacher. Our personal perception was that UOC students, more used to work autonomously, would perform better as the assessment task implied an important process of previous documentation that traditional students are not completely familiar with. So, we hypothesized that, contrary to what most people could expect, our UOC students would perform better and consequently would learn more, or at least as much as, those students attending to regular face-‐to-‐face classes. This paper is structured as follows. Section 2 explains the irrespective settings of each of the universities participating in the study, namely UOC and UAH, as well as the motivation for this research. Section 3 details the design of the research and how the study was conducted, showing the most interesting results. Finally, some conclusions and outlook for more comprehensive studies are provided in section 4.
2. Background 2.1. The Open University of Catalonia The Open University of Catalonia (UOC) is a virtual university with more than 54.000 students all around the world (UOC, 2008). Currently, UOC offers undergraduate degrees in Catalan and Spanish and graduate degrees in English, Catalan and Spanish. UOC has offered university degrees 53
in Computer Science since 1997 and currently more than 6.000 students are enrolled in Computer Science courses. Teaching at the UOC is performed through a virtual campus (Borges, 1998), an online platform which aggregates many services oriented towards students and academics, such as: virtual classrooms where they can access course self-‐study materials, submit assignments and communicate with their peers and the course instructors; virtual laboratories for exercising practical skills (Prieto, 2008); and a virtual library that provides access to recommended bibliography, databases and journals. Academics and students communicate asynchronously using public forums or personal mailboxes. Three academic profiles participate in the UOC learning methodology: the counselor, the subject tutor and the lecturer. Counselors provide orientation throughout the degree, guiding the selection of courses and providing information regarding professional openings, etc. Subject tutors answer questions about a specific course, design the assignments used for the assessment of the course and grade the students. Courses with many students are split into several virtual classrooms, each with a different tutor. Finally, lecturers act as coordinators of the team of tutors for a given course and participate in the course design. While lecturers are full-‐time academics at UOC, subject tutors are professional or academics with full time commitment at another institution or company, and which are selected according to their expertise in a given area. As part of its degree in Computer Science, the UOC offers two 6-‐month courses in compiler design and construction, which are compulsory to achieve the Spanish 5-‐year degree in Computer Science (Ingeniería en Informática). These subjects have many prerequisite courses (programming, data structure, automata theory and computer architecture) and therefore they are among the last courses taken by computer science students, typically in the last year of their degree. Table 1 describes the contents of these courses. The course design has not yet been adapted to the European Credit Transfer System (ECTS), but the workload of each course is estimated at 6 ECTS credits. Table 1. Compiler courses in the UOC Computer Science curriculum. Compilers 1 •
•
• •
Introduction to compilers: history, construction process, compiler architecture. . . Front-‐end: lexical, syntactical and semantic analysis, symbol tables, error recovery Back-‐end: code generation and optimization Construction of a compiler front-‐end using JLex and CUP
Compilers 2 • • •
•
Construction of interpreters Mark-‐up languages (XML) Advanced code generation: procedure calls (pass-‐by-‐value vs pass-‐by-‐reference), object-‐oriented programming languages, . . . Construction of abstract stack machine interpreters and use of XML technologies (DTDs, XSLT, Java APIs for XML)
From the point of view of the students, the workload and difficulty of compiler courses is considered “above average” within the Computer Science curriculum. Some points typically raised to argue for this difficulty are: the use of many concepts and techniques from several prerequisite subjects, highly theoretical contents (e.g. parsing theory), long programming assignments and the introduction of new software tools and languages (constructors of lexical and syntactical analyzers), among others. 2.2. The University of Alcala
54
On the other hand, the University of Alcala (UAH) is a public university located in Alcala de Henares, a Unesco world heritage town located 35 km from Madrid, the capital of Spain. The city, founded in the early 16th century, was awarded the World Heritage status in 1988 because it was the world's first planned university city. The UAH offers 3 different degrees in computer science, the most advanced of which has a duration of 4 years –equivalent to 240 ECTS– and allows the student to obtain the Spanish degree in Computer Science (Ingeniería en Informática). As part of its syllabus, this degree includes a compiler course as a mandatory subject whose main topics are detailed in table 2. Table 2. Compiler course in the UAH Computer Science curriculum. Compilers • • • •
Introduction to compilers: history, construction process, compiler architecture. . . Front-‐end: lexical, syntactical and semantic analysis, symbol tables, error recovery Back-‐end: code generation and optimization Construction of a compiler front-‐end using JLex and CUP
The course follows a blended learning methodology, where face-‐to-‐face lectures are combined to virtual learning and interaction through a Moodle parallel course. Lectures, which are approximately 50% of the total time of the course, address the theoretical foundations of the course, and are taught in a traditional classroom. The rest of the time is dedicated to problem solving cases and assignments. During the practical part of the course, lecturers provide some initial guidance on the tools that students must use as well as a few practical examples on simple applications during 3 to 4 face-‐to-‐face sessions. During these sessions, students raise questions about tools use, installation, technical problems in general and the like. Once they master this part, students face three individual assignments during the rest of the course. During their assignment elaboration, students have access to a virtual learning environment –– specifically set up to enhance both student to student and student to lecturer communication. Students use the virtual learning environment to raise questions on the application of theory to their assignments, technical problems, documentation and other communication activities both with their peers and with lecturers. 2.3. Motivation Two professors from UAH’s Compilers course also work as subject tutors in UOC’s Compilers 1 course. This fact provided the opportunity to compare two learning methodologies, fully online learning versus blended learning, in the context of a Compilers course. To this end, we studied the success rate of students in the assessment activities of both courses. An issue which lends credibility to the results is the fact that students in both universities were evaluated using exactly the same assessment activities, and that the grading criteria were also equal (given that all assignments where graded by the same set of professors).
3. Design of the research The comparison was performed during the first semester of the academic year 2008-‐2009. In the UOC course “Compilers 1”, there were three virtual classrooms, two in the Catalan language with 53 and 57 students respectively, and another in Spanish with 27 students, but only the class in Spanish was used for this preliminary study. In the UAH course, there was only a virtual classroom 55
for the 53 students, even though the students were split into two different groups for the lectures part only for their convenience in terms of space and teaching shifts. There are important differences among the profiles of students at the UOC and the UAH. The UOC is oriented towards life-‐long learning and students which cannot attend a face-‐to-‐face university due to personal or work commitments. Therefore, the students from UOC tend to be older on average (UOC, 2008), have work experience and study part-‐time while working full-‐time and/or caring for their families. It is also common that many students from UOC either have a degree on another area, or started a degree which they interrupted for some reason. On the other hand, students at the UAH tend to be younger and studying their first degree on a full-‐time basis, possibly (but not very often) simultaneously with a part-‐time job. This student profile also has a greater urgency to complete their degree quickly in order to enter the full-‐time job market. These differences in student profiles are significant in the study of the success rate. For example, as time is a very important resource for UOC’s students, students only invest time in solving an assignment if consider they have a reasonable chance of success (rather than failing, they simply will not submit the assignment). Meanwhile, UAH’s students have incentives to work on assignments even if they know their solution will not be optimal (getting feedback from course instructors and avoid “wasting a semester”). 3.1. Teaching and assessment mechanisms In both universities, UOC and UAH, the assessment of the compilers course is carried out in a similar manner. UOC offers theirs students two alternative paths to pass the compilers course: 1. Three continuous assessment activities, followed by a validation test. 2. A final exam at the end of the course. Both paths assess the theoretical concepts of the course and the practical issues as it is shown in table 3 –see how practical aspects play a very important role in these activities and therefore have an important weight in the final mark–. According to experience, continuous assessment improves the assimilation and understanding of concepts, especially in a distance learning environment. Therefore, continuous assessment path is the one recommended by OUC course instructors and the one selected by almost all students. Table 3. Organization of the assessment activities at UOC
• • •
Structure of a compiler (front-‐end/back-‐end, phases, symbol table, . . . ) Compilation vs interpretation Compiler construction (bootstrapping, cross-‐compilers, . . . ) Lexical analysis phase
Practice (70%)
• •
Definition of regular expressions Construction of lexical analyzers using JLex and Java
Theory (30%)
• • •
Syntactic analysis phase Bottom-‐up (LR, LALR) and top-‐down (LL) parsing Syntax error recovery
Practice (70%)
• •
Integration of JLex and CUP Construction of a syntactic analyzer (parser) using CUP and
• Theory (30%) Activity 1
Activity 2
56
Java
• •
Semantic analysis phase (attributed grammars, type checking, . . . ) Code generation phase (intermediate code, . . . ) Code optimization phase (goals, algorithms, . . . )
•
Construction of semantic analyzers using CUP and Java
• Activity 3
Theory (30%)
Practice (70%)
The validation test consists of a set of questions that focus on specific aspects of covered by the continuous assessment activities performed throughout the course. This test has two goals: to certify the identity of the student (i.e. the student has solved the assessment activities herself) and to validate the learning process (i.e. the student has understood the concepts and techniques used in the assessment activities). The final grade is computed as the average grade of all continuous assessment assignments, taking into account that in order to pass the student has to pass all continuous assessment assignments and the validation test. Regarding UAH, the assessment is divided into 2 separate parts: 1. A final exam at the end of the course for assessing theoretical concepts and knowledge. 2. Three assessment activities, followed by a personal interview for validation purposes. These assessments address the practical part of the course only. The final grade is computed here as the average grade of the final exam (60% weight in the final mark) and all continuous assessment assignments (40% weight in the final mark). As in the UOC course, the student must pass all continuous assignments to pass this part of the course, but no student assignment is considered valid if the face-‐to-‐face validation is failed, because this test has the same goals previously described for the UOC: to certify that the student has solved the assessment activities herself and to validate the learning process. Table 4 shows the organization of the three assessment activities at UAH. Table 4. Organization of the assessment activities at UAH Activity 1
• •
Definition of regular expressions Construction of lexical analyzers using JLex and Java
Activity 2
• •
Integration of JLex and CUP Construction of a syntactic analyzer (parser) using CUP and Java
Activity 3
•
Construction of semantic analyzers using CUP and Java
3.2. How the assignments were set up and assessed In this paper, we will analyze the results achieved in the first continuous assessment activity in the semester (from the UOC perspective) and the first assignment (from the UAH perspective) as they have exactly the same tutors/lecturers, the same problem statements and a similar period of time to submit their solutions. Assignments consisted on a set of exercises –both theoretical and practical in the case of the UOC and only practical in the case of UAH– that students must solve on their own. Once the problem statements were published, students had a fixed time (which is usually two to three weeks) to 57
submit their solutions. Each assignment typically requires 4-‐5 hours to be completed, in addition to the time devoted to revising the materials (course materials, recommended bibliography and collections of solved problems). To have two comparable groups of students’ results, only the practical part of the UOC assessment activity was used for the study, so the theory part (30%, see table 3) was removed from it. Thus, the UAH and the UOC assignment activities were exactly the same, which allowed using the same criteria to correct both the students’ results of the UOC and the UAH groups. In particular, the assessments were corrected according to a set of criteria classified into 3 groups: essential (E), positive (+) and negative (-‐). We considered essential those requirements that all the student programs must accomplish as a precondition to pass the assessment, while positive and negative criteria were lists of issues that could have an influence on the final mark. More detail on the criteria followed by the courses’ tutors is given in table 5. Table 5. Correction criteria Type of criteria
Description
Comments
E
The archive.lex must be processed by JLex without errors
E
The resulting Java file must compile without errors
Some minor errors were not considered, e.g. using a class name for the scanner other than the one requested
E
The scanner created by JLex cannot end unexpectedly (e.g. due to a not handled exception or the like)
+
The specification file is legible and include comments
+
Lexical patterns are simplified through Usually linked to the previous criteria the use of macros
+
Java code is well structured
The specification file has a method for each functionality instead of having the java code repeated several times
-‐
The specification file does not include the directive %class to change the default scanner class name
One mark was cut out of 10
-‐
The specification file includes too many One mark was cut out of 10 states, most of them unnecessary
-‐
Bad Java code in the specification file
-‐
The student makes use of inefficient or 0.5 mark was cut out of 10 inadequate data structures
0.5 mark was cut out of 10
During all the period of assessment, and up to the deadline for submission, the course instructors were available to answer questions regarding the materials or the comprehension of the 58
assessment wording. In the case of UOC, this help was of course available through the virtual environment, whereas in the UAH the lecturers allocated 2 hours per week to face-‐to-‐face help sessions in the lab, in parallel to the help they provided through the virtual environment. 3.3. Analysis of the results Our initial thought was that students in blended learning would achieve better results than students in an exclusively on-‐line environment, as they have more direct access to lecturers both through the online environment and in the face-‐to-‐face sessions. However this was discarded by just comparing basic descriptive statistics as shown in table 6. Also, and even though the marks do generally follow a normal distribution, this is also confirmed as both standardized skewness and kurtosis are inside the range of ±2. Table 6. Descriptive Statistics Count Average Variance Standard deviation Minimum Maximum Range Standard skewness Standard kurtosis
UAH 53 6.24717 3.57831 1.89164 3.0 9.5 6.5 -‐0.48213 1.29985
UOC 27 6.95185 6.03413 2.45645 1.4 10.0 8.6 1.48045 0.837939
This is also corroborated by the box-‐and-‐whisker plot of Figure 1. As it can be observed, although there is more variance for the on-‐line learning groups, the mean of the marks is higher.
Figure 1. Box-‐and-‐whisker plots for marks To check whether the difference between the means was statistically significant, we run a t-‐test with the following null hypothesis: H0: There is no difference between the means (i.e. the means are the same) Therefore, the alternative hypothesis, Ha, is that there is a difference between the means. Selecting a=0.05, the f-‐test for the equality of variances shows that there is no statistical difference between the variances of both groups and a t-‐test assuming equal variances could be applied (see table 7). 59
Table 7. F-‐Test Two-‐sample for variances Mean Variance Observations df F
UAH 6.24717 3.578309 53 52 0.593012
UOC 6.951852 6.034131 27 26
P(F<=f) one-‐tail F Critical one-‐ tail
0.054473 0.584925
As it can be seen in table 8, the t statistic is lower than the t critical (.23727< 2.30601), and also the p value is greater than a (.0.079 > 0.05). According to this, we can accept the null hypothesis that there is no statistical difference between the means. Table 8. t-‐Test: Two-‐sample assuming equal variances Mean Variance Observations Pooled Variance Hypothesized Mean Difference df t Stat P(T<=t) one-‐tail t Critical one-‐tail P(T<=t) two-‐tail t Critical two-‐tail
UAH 6.24717 3.578309 53 4.396916
UOC 6.951852 6.034131 27
0 78 -‐1.42133 0.079604 1.664625 0.159208 1.990847
Based on the marks obtained in our experiment, we can conclude that knowledge acquired in blended or exclusively online learning is similar. 3.4. Threats to validity We faced 3 different kinds of threats to validity: those concerning the construct validity, those concerning the internal validity and those concerning the external validity of our experiment: •
Construct validity is the degree to which the variables used in the study accurately measure the concepts they purport to measure. In our case, marks were the only way to measure the student´s acquired knowledge.
•
Internal validity is the degree to which conclusions can be drawn about the causal effect of the independent variable on the dependent variables. Potential threats include selection effects, non-‐random subject loss, instrumentation effect, and maturation effect. Although the students are different, it is noting that we only considered students handing in their assignments. Another possible threat is that both groups did not have the same time to work on the assignment (2 weeks for the UOC students vs. 3 weeks in the case of the UAH students). 60
•
External validity is the degree to which the results of the research can be generalised to the population under study and other research settings. Although students in the online course are more mature than in the blended group, their initial knowledge was similar. The only possible difference is that the teaching materials were not identical in both cases.
4. Conclusions and future work The research reported on the comparison of two courses on compiler basics, one fully online given at the Open University of Catalonia (UOC) and another blended one given at the University of Alcala (UAH). The study reported herein was restricted to the first assignment activity of the course as the other 2 were not finished by the UAH course by the deadline. Even though some factors change and the conditions and context cannot be demonstrated to be identical, most conditions were: the assessment to carry out, the teachers who acted as tutors and the evaluation criteria. We first carefully studied possible threats to the study validity, considering all different aspects and concluding that those threats did not have a central influence on the results of our experiment. The tests run on the marks of both groups of students allowed us to conclude that the amount of knowledge acquired in blended learning (UAH) and in exclusively online learning (UOC) is similar. Further work should progress on a more comprehensive study, covering all the stages of the compilers course, namely activities 1 to 3 and not only the activity 1. Also, studying new factors such as the lecturers influence (e.g. do students in other groups perform differently?), time given for assignment resolution, students’ age, etc. would be helpful for getting more comprehensive conclusions. Replications over several years are also a target to address external validity.
Acknowledgements The authors would like to thank Francesc Bagés and Alex Pajuelo for their collaboration in Compilers 1 at the UOC and discussions about the design of Compiler courses.
References Anstine, J., & Skidmore, M. (2005). A small sample study of traditional and online courses with sample selection adjustment. Journal of Economic Education, 36(2), 107-‐127. Borges, F. (1998). UOC and its 'Campus Virtual': A Model for Online University Education, In Proceedings of the 2nd North American Web Developers Conference (NAWEB 98), New Brunswick, NJ, USA. Open University of Catalonia (2008). Annual report 2007-‐2008. URL: http://www.uoc.edu/portal/_resources/EN/documents/memories/0708/memo_eng.pdf Prieto, J. (2008). Ontology-‐based characterization and specification of virtual laboratories in Computer Science degrees. PhD thesis, Universitat Oberta de Catalunya.
61
Learning Engineering by Modeling a Guitar Effects Pedal with FPGAs Joaquín Olivares, José M. Palomares, José M. Soto, Juan C. Gámez Department of Computer Architecture. University of Córdoba. Campus Rabanales. 14071. Spain {olivares,jmpalomares,jmsoto,el1gagrj}@uco.es
Abstract Several Supervised Academic Activities have been proposed in the subject “Digital Electronic Systems” th carried out in the 4 year of Engineering Degree in Automatics and Electronics. The purpose of these works is to implement digital systems in FPGA technology. With these supervised works, the students will be able to prove their knowledgement of the subject. Furthermore, the realization of these works will permit to develop cross-‐activities with others subjects. A project-‐based learning methodology is applied, focusing in this paper in a particular work from one student that consisted in implementing a guitar effects pedal. This activity has been awarded as the Most Innovative Activity of 2007 for this degree by the University of Córdoba.
1. Background Different learning patterns are developed by the students even if they use the same methodology, learning, tools and contextual factors. These differences are owing to personal and contextual factors (Vermunt 2005). Several works present the benefits obtained when individual learning was applied (Liu et al. 2008). These benefits increased when student’ emotions were considered (Lekkas et al. 2008). Because of its particular feature, these differences in learning process are very important in our degree. The subject has around twenty students enrolled from several universities B.S. in Engineering Degrees of three years as Electronic, Electrical, Mechanical or Computer Science. This is the reason whereby students are not completely informed in initial concepts. Therefore, it is necessary to establish a special work timing for everyone The Digital Electronic Systems subject is structured in three thematic blocks (Olivares 2007). The first block is a review of programmable logic devices, DS, and design of DS, and takes about 20% of the total. The second block is dedicated to train the students in advanced hardware programming, using FPGA devices and VHDL language, takes about 60% and is the most important thematic block of the subject. Finally, the last one is dedicated to show the microcomputer as a complex digital system, taking the remaining 20% (Olivares et al. 2008). The students have two different ways of passing the subject: a final and common exam or an individual project. Such project must have an adequate complexity in order to guarantee that students have learnt all the contents proposed in the subject. Furthermore, the students must carry out the project spending the determined hours assigned in the subject guide. The old methodology consisted on a more rigid approach. The 40% of the assessment depended on a series of obligatory practical works. The remaining 60% depended on the final examination. Moreover, several optional works could be considered in the final assessment whenever students pass the subject. Practical works and exams are needed to succeed in passing the subject. However, whenever students pass the subject; it is possible to consider several optional works to improve the final assessment. Due to this methodology all students developed the same practical works. In this way, one can find some negative aspects, which infringe the above mentioned 62
guiding principles (Mathematical, 1993). Equity is not ensured, because all students have unlike knowledge and this might produce different reactions given the situation: practical works too complex for some students or too easy for others. Although the main aim of the proposed activity is to know the concepts of the subject, it is also interesting that the projects contribute to learn or to introduce other subjects, promoting horizontal cross activities (in the same academic course) and vertical cross activities (between current and next academic years). Finally, the students must acquire the ability to design and solve industrial problems. In the last two years, a new methodology based on individual projects was proposed to the students. Project-‐based-‐learning was suggested as a promising pedagogical approach for teaching technological problem-‐solving (Mioduser and Betzer, 2007). The professor suggests each student to develop a particular project in which personal interests were included. Furthermore, the students would be able to suggest themselves their own project provided that it is relatively complex and understable and that it is approved by their professor. This methodology presents a notable improvement in assessment such as it is shown in Section Results In our suggestion, each student has a project that matches his personal interests. Furthermore, the students themselves can suggest their own project, provided that it is complex and comprehensive enough, and that it is approved by their professor. This methodology presents a notable improvement in assessment as is shown in Section Results. The Tuning competences (Tuning 2007) that have been considered as the most important ones for the professional development in this degree are listed below. The aim is to develop these skills among all subjects of the degree:
Capacity for analysis and synthesis.
Basic knowledge of the field of study.
Capacity for applying knowledge in practice.
Capacity for generating new ideas (creativity).
Capacity to learn.
Critical and self-‐critical abilities.
Knowledge of a second language.
With this experimental methodology, different projects will be assigned to different students according to their features. These projects should agree some requirements, in order to ensure the guiding principles: 1) the project is individual, 2) it involves the majority of methods and tools considered within the subject, and 3) it is complete and relatively complicated. These requirements are indispensable for a good assessment, as other experiences reveal (Sklyarov and Skliarova, 2005). In addition we also give our students the opportunity to choose to be examined by means of the old methodology or by the new proposal. All of them voted for the new methodology. All skills are developed with the proposed methodology, with the exception of the “capacity for generating new ideas”, that can be suppressed in basic projects proposed by the professor. A typical assessment criterion in Spain is the range of values between 0 to 10 points; the students need to reach a degree of 5 or higher in order to pass the subject. 63
When the professor suggests the list of projects, he informs the students of the highest evaluation possible attainable with each one. Simple projects with a highest value of 5 are possible, though in this case, a project previously limited to 5 is a project that covers minimum concepts and skills required to pass the subject. In this way, a project limited to 10 must cover advanced topics and to guarantee that the students learn completely the subject. When a determined student proposes a project, the professor studies the proposition and sets the maximum value that the student can obtain with it. The final evaluation obtained for a student is based on the percentage shown in Fig. 1. This percentage is applied to the maximum limited value for the project.
Fig. 1: How to evaluate a project In this contribution, a distinguished project is described in order to present the motivation to select the projects’ contents, how the bases are related with other subjects, and, which competences are developed.
2. Discussion. A project-‐based learning example The design of a guitar multi effects pedal and its implementation in an FPGA device was proposed in the first semester of 2007. This specific project was proposed for one student who enjoys playing the guitar, and he was very interested in it. The project was accepted because it was complex enough and covered the main concepts of the subject. Furthermore, advanced concepts were also introduced. The highest value possible which a student could obtain was 10 points over 10. All competences listed in the previous section were considered. The proposal included the implementation of the following guitar effects: Echo, Flanger, Phasing, Chorus, Clipping, Wah, Phaser, and Distortion (Hunter, 2004). Once the FPGA was programmed with the audio processor designed by the student, speakers and a music source, as an iPod or an electric guitar, were connected to the system to prove that the system worked correctly. The interface with the development board was the buttons and switches to select the effect and its strength, and the 7-‐segments led to see basic information about the processing. To solve this problem a previous mathematical model of each effect was solved on Matlab simulator. In this project an analog to digital converter (ADC), and digital to analog converter (DAC) were used on a controller board. Also memory "first input, first output" (FIFO) buffers were used. Real time processing concepts were introduced with this project. The proposed system is shown in Fig. 2.
64
AK4551
Audio Codec Interface
Read/Write
Signal adder
Distortion
SDRAM Controller
SDRAM
FPGA
Input Buttons
Switches 7-Segments
Fig. 2: Design of the proposed system To develop the design, the student used previous knowledge acquired in other subjects during the same semester. The subjects of the following semester or year were also introduced. Related subjects are shown in bold in Fig. 3. 65
4th Year
First Semester
Last Semester
Electric Machines
Industrial Electronics
Optimization
Control Engineering I
Digital Electronic Systems
Modeling Dynamic Systems
Mechanics Systems
Human-Machine Interface
English
Computer Architecture
Scientific Programming
Applied Electrics
Intelligent Buildings
5th Year
Electropneumatic
Control Engineering II
Programming Robots
Perception Systems
Projects
Industrial Power Electronics
Integrated Production Systems
Safety at Automatic
Real Time Systems
Process Control
Engineering Materials
Advanced Power Electronics
Microelectronics
Computer Networks
Digital Signal Processing
Fig. 3: Organization of the cross knowledge Then, a description of the introduced subjects and the knowledge related for each one is summarized: This academic year:
English: Documentation reading. We remind our students that final project presentation hd to be presented into English Language. In that case, the English professor was the responsible person for evaluating this part.
Scientific Programming: Simulation was carried out by using MatLab and Simulink.
Control Engineering I: Concepts about filter and sampling signals are introduced.
Computer Architecture: The use of memory and FIFO buffers is introduced.
Next academic year:
Control Engineering II: Advanced filters.
Projects: How to write a dossier.
Real Time Systems: The proposed effects are processed and shown while playing music. Initial concepts on real time processing are required.
Digital Signal Processing: Using ADC and DAC. Digital signals.
The instrumental used to develop this project, shown in Fig. 4, was:
A XESS XST-‐3 board, provided with audio codec, ADC, DAC, SDRAM memory, I/O ports and a Spartan-‐3 "XST-‐3S1000" FPGA from Xess (Xess 2005). 66
An electric guitar; that could be substituted by another music source such as an iPod, microphone, etc.
Speaker.
Fig. 4: The guitar effects pedal implemented in an FPGA
3. Other projects developed All projects were implemented on FPGA devices and had a common component based on the use of input/output peripherals, memory and computer architecture concepts. To implement these projects, the students used FPGA devices such as "Spartan 3 Board" from Digilent Inc. The most common work about peripherals used the VGA, because of the complexity to configure the synchronization signals. Moreover, other devices such as the PS/2 mouse and keyboard were used. In most cases, the matter was about games, because of the attractiveness for the students (Carmona et al. 2008), (Tam et al. 2008). Moreover, this kind of projects provides authentic tasks, i.e., tasks which are similar to that performed in "real life". This is a key principle of a good assessment (Waters and McCracken, 1997), (Baker et al. 2005). A good example of this was the implementation of the typical game called ``Simon'', with a visual version. A random color sequence is showed on VGA, the player tries to reproduce this sequence to pass the game level. To accomplish this game, it is required the hardware VGA control, random generator based on internal oscillator, and, external interaction with keyboard or switches. In other project, a lap counter visualized on VGA was implemented and adapted for a slot cars racing game called “Scalextric”. In this case, electronics and electrical concepts were used in order 67
to adapt a basic Scalextric track introducing two photocell sensors. Besides, a small electronic board is designed to connect the sensors to the programmable digital system on FPGA. Learning about asynchronous signals was reached with this kind of projects. In the same way a typical 9-‐puzzle was designed. Keyboard data input, random generator and VGA controller was used in this project. The typical game called Ricochet was designed by using a previous open source version (Goga and Andrei, 2005). In this case, to review and understand a previous design was the first part of learning; later, the student added a new module which consisted on a shooting button. In the design of this new option, interaction with other modules must be updated by the student. Finally, the game was controlled with keyboard and board' buttons, besides a clock divisor was used to control the speed of different game components. A game picture is presented in Fig. 5. Fig. 5: The Ricochet
4. Results A notable improvement in assessment compared to previous years can be observed. In Fig. 6, the students' assessment is shown with the results of the last three years compared to the previous four academic ones. The Old Methodology corresponds to 2002-‐2005 academic period, whereas the New Methodology based on projects corresponds to 2006, 2007 and 2008 academic years. In Spain, the range of values in which a student is evaluated goes from 0 to 10 points, and the student passes the subject when obtaining 5 points or above. An equivalence with the english assessment system could be stated as: (A+) Pass with honors, (A) Pass 9-‐10, (B) Pass 7-‐8, (C) Pass 5-‐6.
68
Fig. 6: Assessment evolution The 2002-‐05 values represent the arithmetic mean of the assessments of these four academic years. The 2006 was the experimental year, that is, the year in which we started the new methodology. In that year we could observe an improvement compared to the average of the previous four years. Similarly, we obtained better results in 2007 and 2008, due to a more precise selection of the amount of time assigned to fullfil the projects. This meant an improvement in the results, as stated in Fig. 5, where 'Fail' percentage fell from almost a 40% of students who failed the subject to a figure below 25% (23%, 8%, and 25%, respectively, in 2006, 2007, and 2008). Moreover, this behavior is also shown for students with C grade, for which a reduction from 42% to 30% was obtained in 2007 and even more for 2008 with no student obtaining a C grade. It is worth mentioning that 2006 has to be taken as an exception, because, for C grade, there was a rising leap to 54% of the students. This happened because the students were able to finish their projects, but just to the minimum required level due to lack of time for further enhancements. For A and B grades, new methodology courses show a significant growing. Finally, no A+ grade was granted (from 2002 to 2006) and in 2007 and 2008 (with the new methodology) aroung 10% of the students obtained such a honored grade. 4.1. Advantages and drawbacks The first advantage is the motivation that these practical works raise a great interest in the students, because they have to work in FPGA and their projects are games. Because of the projects are personal practical works, it is possible to evaluate features such as difficulty, ability, dedication, etc. Due to this, the subject can be adapted in a high grade to students' particular features. Furthermore, this methodology reports continuously on student progress. From the students' point of view, they have the opportunity to evaluate and reflect on their own understanding (Waters and McCracken, 1997). To expose the projects in a foreign language improves the student capacity of expression, contributing to develop the team in an international work competence. 69
The main drawback comes up because it is necessary an important teacher support for each student. In this current academic year, this disadvantage has been mitigated with a scholarship to assist to the students. At the beginning of projects, some students can feel an uncertainty about their own ability to solve the project, but this uncertainty disappears with the course evolution.
5. Conclusions The experience was successfully for students. The assessment presents an important improvement since the failed in previous years was around 40% and by applying the new methodology the failure decreases to a mean of 25%. Moreover, the number of students with graded 7 or more rose to a mean of 53%. Competences listed on discussion section are all developed and evaluated. Moreover the student's capacity to design and to develop industrial electronic systems, based on reconfigurable programmable devices, is guaranteed. This experience corroborates how a methodology based on projects is more appropriate for determined subjects with a high practical component than traditional methodologies based exclusively on examinations. Although reduced groups of students are really necessary due to the high teaching support which is required by each project. With this methodology, two goals are achieved; to guarantee that students are able to perform industrial FPGA designs, and to begin cross activities with other subjects. Obviously, the learning of the essential concepts of the subject is granted. Tuning competences were developed using the proposed educational methodology. An improvement in the assessment and in the learning is achieved, students are more motivated and are more active in the learning process. With the “guitar effects pedal” project, the students passed the subject with honors and a final evaluation of 10. This project was awarded in December 2007 with the Most Innovative Activity of the Year for this degree at the University of Córdoba.
Acknowledgements This work was partly supported by the Xilinx University Program and the Vice Chancellor of European Higher Education Area and Undergraduate Degree Programs.
References A. Baker, E. Navarro, A. van der Hoek. (2005). An Experimental Card Game for Teaching Software Engineering. Journal of Systems of Software, 75. C. Carmona, D. Bueno, M.A. Jiménez (2008). Adapting an Educational Game for Spanish Ortography to Make it Adaptative and Accessible. Eighth IEEE International Conference on Advanced Learning Technologies. D. Hunter. (2004). Guitar Effects Pedals – The Practical Handbook. Backbeat Books. London. Tuning Project. (2007). Tuning General Brochure. Z. Lekkas, N. Tsianos, P. Germanakos, C. Mourlas, G. Samaras. (2008). The Role of Emotions in the Design of Personalized Educational Systems. Eighth IEEE International Conference on Advanced Learning Technologies. 70
T.-‐C. Liu, Y.-‐C. Lin, Kinshuk, M. Chang. (2008). Individual Differences in Learning with Simulation Tool: A Pilot Study. Eighth IEEE International Conference on Advanced Learning Technologies, doi: 10.1109/ICALT.2008.302. D. Mioduser, N. Betzer. (2007). The contribution of Project-‐based-‐learning to high-‐achievers’ acquisition of technological knowledge and skills. International Journal of Technology and Design Education. vol. 18. n. 1. pp. 59 – 77. J. Olivares. (2007). Guía Docente de Sistemas Electrónicos Digitales. Córdoba. Escuela Politécnica Superior. http://www.uco.es/organiza/centros/eps/doc/programas/570006.pdf. Accessed 10 May 2008. J. Olivares, J. Gómez, J.M. Palomares, M.A. Montijano. (2008). Biprocessor SoC in an FPGA for Teaching Purposes. Eighth IEEE International Conference on Advanced Learning Technologies. V. Sklyarov, I. Skliarova. (2005). Teaching Reconfigurable Systems: Methoods, Tools, Tutorials, and Projects. IEEE Transactions on Education, 48(2). M. Spector, R. Hartley, R. Koper, Kinshuk, A. Elsayed. (2008). A Competency Approach: Implications for E-‐Learning and E-‐Assessment. Eighth IEEE International Conference on Advanced Learning Technologies. V. Tam, Z.X. Liao, A.C.M. Kwan, C.H. Leung, I.K. Yeung. (2008). Developing an Interactive Game Platform to Promote Learning and Teamwork on Mobile Devices: An Experience Report. Eighth IEEE International Conference on Advanced Learning Technologies. J.D. Vermunt. (2005). Relations Between Student Learning Patterns and Personal and Contextual Factors and Academic Performance. Higher Education. 49. pp 205 – 234. R. Waters, M. McCracken. (1997). Assessment and Evaluation in Problem-‐Based Learning. The 27th Frontiers in Education Conference. Xess. (2005). Xstend Board V3.0 Manual. http://www.xess.com/manuals/xst-‐manual-‐v3_0.pdf. Accessed 25 July 2008.
71
Using IMS-‐LD Standard to Support Learning in Teaching ICTs in Industrial Design Engineering Rocio Garcia-‐Robles(1), Fernando Díaz-‐Del-‐Río (2) (1)
Escuela Técnica Superior de Ingenieria Informática, Universidad de Sevilla Avda. Reina Mercedes s/n, Sevilla 41012 [email protected] (2)
Escuela Técnica Superior de Ingenieria Informática, Universidad de Sevilla Avda. Reina Mercedes s/n, Sevilla 41012 [email protected]
Abstract IMS-‐Learning Design specification was designed to support the authoring of reusable and pedagogically neutral learning scenarios and contents. Although it is especially suitable for eLearning, its use in traditional face-‐to-‐face Higher Education scenarios may be interesting, mainly because it supports formal description of teaching practices, and that type of information oftenly remains as tacit knowledge in HE learning scenarios. This paper presents the outcomes of using such standard to innovate teaching practices in “Introduction to Informatics”, a subject taught in the Industrial Design Engineering School at University of Seville. Its pedagogical design is based on the IMS-‐LD standard, and is implemented using Blackboard, which is the University of Seville institutional web based Learning Management System (LMS). Design and implementation results are presented and analyzed, and some benefits of using IMS-‐LD are remarked.
1. Introduction Learning Design (LD) specification aims at representing the 'learning design' of 'units of learning' (UoL), in a semantic, formal and machine interpretable way (Koper & Olivier, 2004). A UoL may be any instructional or learning event of any granularity, e.g. a course, a workshop, a lesson or an informal learning event. A 'learning design' is defined as the description of a teaching-‐ learning process that takes place in the UoL (Griffiths et al., 2005). The key principle in LD is that it represents learning activities and support activities that are performed by different persons (learners, teachers) in the context of a UoL. These activities may refer to different learning objects that are used in the performance of the activities (e.g. books, articles, software applications, pictures), or they can refer to services (e.g. forums, chats, wiki's) that are used to contribute to the teaching-‐learning process (Griffiths et al., 2005). The Learning Design specification can be seen from (at least) four different perspectives: (1) An educational modelling language; (2) an eLearning methodology; (3) a set of applications; (4) and an interoperability specification (Burgos & Griffiths, 2005). This specification has been developed to meet some specific requirements: Completeness, Pedagogical expressiveness, Personalization and Compatibility (Koper, 2006). In the Computer Architecture Department of the University of Seville (US) in which the that subject is taught, completeness and pedagogical expressiveness are considered key issues. Additionally the new European Higher Education Area (EHEA) promoted by the Bologna process demands innovative pedagogic approaches, and IMS-‐LD may support them.
72
2. Design of the learning scenario The LD specification consists of several components, one of them being the IMS Best Practice and Implementation Guidelines (IMS-‐BPIG, 2009). According to those guidelines, the design and development of education is an incremental process that systematically follows the stages of analysis, design, development, implementation, and evaluation. The following steps are to be taken in order to proceed from a description of an educational problem to a learning scenario: 1. The analysis phase should result in a didactical scenario that is captured in the form of a narrative. 2. The narrative of the analysis stage is taken and cast in the form of a series of (nested) UML activity diagrams. The UML diagrams capture the workflow aspects of the narrative. 3. An XML document instance for the UoL will be put together on the basis of the UML activity diagrams. Any XML document instance should be valid against the LD Specification. Using IMS-‐LD solely as a methodology involves steps 1 (analysis) and 2 (design). The corresponding roles description and an example of UML activity diagrams are presented below. Contents: There are three UoLs: Introduction to Computer Systems, User Interface Design, Algorithmic & Programming. Those three parts allow the students to develop basic competences and skills in the first semester of the first level of the Industrial Design Engineering degree. The number of students is up to 220 split in two groups for theoretical classes, and in four groups for practical classes. That means there are more than 50 students per teacher in the practical classes. That huge amount of students makes difficult to innovate teaching practices for the whole subject. Therefore: the first UoL was taught according to an instructional single-‐learner pedagogic model; the second UoL was based on a problem based learning scenario in which students were working in groups; and the third UoL was approached in a mixed way: working in pairs in face-‐to-‐face sessions, but with a single-‐learner evaluation. For the purposes of the current paper the second UoL is analyzed in detail, because using the IMS-‐ LD specification as methodology is specially interesting for collaborative learning scenarios. Roles and activities are described for User Interface Design Case Study (CS). Roles: Teachers’ roles: •
Facilitator (FA): In principle, all the teachers (three in that subject) play the role of FA, stimulating students in their social-‐constructivist experience. So, the terms teacher and facilitator can be considered equivalent.
•
Coordinator (CO): One of the facilitators will play the CO role. The coordinator has to design the CS description.
•
Evaluator (EV): At least, one of the facilitators will play the EV role. The evaluator is responsible for assessing and evaluating groups and individual proficiency. Nevertheless, FA is also partially involved in the evaluation.
The afore-‐mentioned teachers’ roles can be played by the same or by several persons. For that subject taught at Industrial Design Engineering, one teacher was the CO, and the three of them were FA and EV in their respective classes. 73
Students’ roles: •
Student (ST): In principle, all the students play such a role. But, in order to promote organizational skills, other roles are taken into account.
•
Chairperson (CP): On behalf of the entire group, he/she is in charge of the communication with external partners (other groups’ CPs and the FA). The chairperson, the spokesperson for the group, is responsible for recording key group decisions, and the chosen representative must be appointed as such by the facilitator. This role implementation also benefits the FAs, because it scales the communication workload between students and FAs.
•
Speaker (SK): He/she is the person who must present the outcomes of the final CS solution in the corresponding final face-‐to-‐face session. He/she must also discuss with the rest of the CPs and SKs at this session.
Activities: The activity dynamic is described by using UML diagrams. A few of them are shown in current paper: Global learning scenario (fig.1), and the rest of them (fig.2, 3 and 4) corresponding to UoL2: User Interface Design Case Study.
Fig. 1: Global Learning scenario. The Global Learning Scenario is composed of several activities. The first two are preparatory work (designing learning and content by all the teachers coordinated by the CO role), and logistic tasks (corresponding to the starting of the teaching activity at the beginning of the semester; they include creating group of students and assessment activities).
74
Fig. 2: UoL2: User Interface Design Case Study. In relation to the UoL2 (see fig. 2), there were two milestones. The first one was scheduled to promote learners to work hard in the CS since the very beginning. Once the initial milestone delivery took place, there were no other marked milestones until the end, which happened at the end of the fifth week, just before the final face-‐to-‐face session. In the final milestone evaluation & feedback all the teachers were involved. In some groups, the EV role was played by a different person than the usual FA role. In other groups both roles were played by the same teacher. Students’ work in groups (see fig. 3): Every student in the group reads the problem (by downloading the corresponding PDF documents from the LMS). The group then meets up (they may use synchronous or asynchronous facilities of the LMS) and discuss how to clarify the problem and plan work scheduling. They eventually arrive at their own succinct statement of the problem at hand. Once this is done, the CP states the problem, and interacts with the FA to clarify open issues and agree on a work schedule. Students can use any communication tool available in the LMS, (e.g. chat, email,…) It is important to note that, in order to scale teacher-‐student interaction, on one hand students only communicate with the FA via the CPs and, on the other, the FA creates a FAQ (frequently asked questions) list published in the LMS containing the most popular and interesting issues arising from the interaction with CPs. Then the CP states the discussed solution and uploads it to the LMS before the deadline. All the CPs discuss the different submitted solutions (via the LMS). In the meantime, the FA reads the solutions and monitors CPs’ discussion. (by using synchronous tools –e.g. public forum, and asynchronous tools – such as email) 75
Fig. 3: Students’ work in group. Face-‐to-‐face session (see fig. 4): The CPs discuss other groups’ solutions. Helped by the rest of the students from his/her group, the CP can defend or even rectify their solution. CPs can also ask the FA about issues that have arisen. At the end of the discussion, the FA provides assistance, clarifies, gives some support for further work and finally gives some feedback on group and individual progress.
Fig. 4: Face-‐to-‐face session.
3. Results after implementation of the learning scenario Three types of evaluation are being taken into consideration to detect the pros and contras of the proposed method: 1. Students’ opinion 2. Teachers’ opinion 3. Students’ marks During the first semester, the three teachers involved in the subject did several interviews to 76
collect students’ opinions. Interviews were done to random selected students (during some minutes in the face-‐to-‐face sessions). All the interviews were very positive because students pointed out the advantages, but also the main difficulties to carry out with this subject. The most interesting were the opinions of students who abandoned the subject the previous year. Some of them stated: “weekly milestones suppose more workload during the semester but encourage us to follow the subject”; “doing a task to deliver a document makes us to understand the objective of the UoL”; “evaluating not only knowledge, but also the competencies is a more fair evaluation procedure”. Of course students give their bad/good impressions about working in group; in fact most students were not skilled in this capacity, so usual problems were detected in some groups. Furthermore an opinion test composed of ten questions has been prepared to collect a more statistical result. This test is going to be asked during the last part of the second semester by the University of Seville services. It was not undertaken before because the aim is that student compare that subject pedagogic method with the rest of the subjects they are studying in the current academic year . For this reason this result is not available yet. With respect to teachers’ opinions, all of them think that workload has to be measured for the next course. During current course the high amount of changes introduced in the methodology made difficult to calibrate the different workloads. Due to the fact that all the teachers were involved deeply in those changes, the particular opinions were very subjective and not relevant for the moment. For the next course, we are considering that teachers’ opinions should be collected by an external agent. Finally marks for students are considerably better than those of previous year counterparts as it is shown in fig. 5. It is obvious that the methodological change has had a positive impact in the marks. We think that a key issue had a main influence in marks: students motivation due to the weekly guidance and feedback. In fact much fewer students have abandoned the subject during this year (36% while the abandon rate was huge during previous year, 76%). Another question that might have a positive impact is the renovation taken in terms of content. While statistical tests are not yet available, students’ interviews told us that this last factor was not crucial.
Fig. 5: Students’ marks: semester 2007-‐2008 (left), semester 2008-‐2009 (right).
77
4. Benefits of using IMS-‐LD Some benefits of adopting IMS-‐LD in a traditional Higher Education (HE) institution are: 1. It promotes the use of role models to support a distinction between possible roles and real actors. Explicit distinction between roles addresses the division of responsibilities improving coordination and supporting tasks, and making solution easily scalable regardless of number of involved teachers. 2. It promotes the structuring of activities such as preparatory work, logistic tasks, sequential activities, etc. Therefore the process dynamics –which is a key issue in the teaching/learning experience–, is made explicit. Moreover it helps to distinguish between learning and support activities. Although it is usual to take into account such a distinction, it should be made explicit in the pedagogical design from the very outset to prevent the coordinator from becoming overloaded. 3. Allocation of resources and environments is also made explicit when designing a pedagogical scenario using IMS-‐LD. In this way, it is easier to think in terms of scalability and feasibility when allocation is clearly defined from the outset. 4. Reusability of learning design is promoted. Of course, teachers must review designed and implemented scenarios to adapt them to the new performance or subject. But design and adaptation costs are estimated to be very low once the course or UoL has been designed and implemented. 5. To schedule teaching and learning activities in design time promotes quality improvement, although it is usually necessary to do further adjustments in implementation time (i.e. when the students are already involved in the course). 6. If the long run, once we have used the LD methodology for a substantial period of time, it should be possible to extract pedagogical patterns that help teachers identify the best teaching and learning practices, assisting academic community with reporting and performance analysis. This outcome should have a clear potential benefit that must be considered when adopting a corporative strategy for innovation purposes in educational practices.
5. Conclusion On one hand, the teachers involved in this trial have concluded that the IMS-‐LD specification is a very useful methodological tool for formalizing the design of pedagogical scenarios. In fact, they have used the methodology included in the IMS Learning Design Best Practice and Implementation Guide (IMS-‐LD BPIG, 2009), as it is explained above. On the other hand, some important drawbacks regarding with using IMS-‐LD were identified, and some decisions were taken, as follows: •
Teachers working in the department are willing to innovate their teaching practices, as long as the increase in their workload is kept to a minimum. As they have to combine teaching and research activities, additional workload of using learning standards must be minimized. Additionally a very high level of detail (related to a granularity of specification) is required to make a machine-‐readable version of a UoL. Bearing in mind these issues, a good solution is to use IMS-‐LD just as an e-‐learning methodology. That means that using that specification makes sense although development and implementation stages are 78
missing. •
The initial effort needed to create a pedagogical scenario using that specification is likely to be greater than a situation when teachers think in terms of content and split responsibilities among them. But the return of the time investment is achieved soon, in the next semester. Moreover it is also possible to compensate individual efforts by distinguishing the “learning designer” role to compensate additional workload between teachers.
References Burgos, D., Griffiths, D. (2005). The UNFOLD Project: Understanding and Using Learning Design, Open University of The Netherlands, 25-‐30. Griffiths, D., García-‐Robles, R. et al (2005). Learning Design, Springer-‐Verlag, 109-‐135. IMS LD Information Model, pp 71, www.imsproject.org IMS LD Best Practice and Implementation Guide www.imsglobal.org/learningdesign/ldv1p0/imsld_bestv1p0.html Koper. R., Olivier, B. (2004). Representing the Learning Design of Units of Learning, Educational Technology & Society, 7 (3), 97-‐111. Koper, R., (2006). Current Research in Learning Design, IEEE Journal Educational Technology & Society 9 (1), Special Issue on Learning Design, 13-‐22.
79
Devising instruction from errors in students’ assignments: a case in usability engineering education Elena García-‐Barriocanal, Miguel-‐Angel Sicilia, Salvador Sánchez-‐Alonso, Daniel Rodríguez Information Engineering Research Unit Computer Science Dept., University of Alcalá Ctra. Barcelona km. 33.6 – 28871 Alcalá de Henares (Madrid), Spain {elena.garciab, msicilia, salvador.sanchez, daniel.rodriguezg}@uah.es
Abstract Problem-‐based learning emphasizes the role of problem solving as the main driver of instruction, thus critically relying on the quality of problem collections, which should exercise especially those aspects students find difficult to master. In areas in which extensive and tested problem collections are not available, it is useful to analyze the mistakes of students in previous year’s assignments as a source of evidence for the design of new problems or tutorial resources. This paper reports preliminary results of that approach as applied to heuristic usability evaluation in the context of an introductory Human Computer Interaction course. The process is described, and some examples are reported as concrete cases in which assignment analysis lead to insights for devising instruction.
1. Introduction Problem-‐based instruction has been subject to significant research interest in recent years (Merril, 2007). Problem-‐based strategies share as a central concern the design of problems that cover the complete spectrum of knowledge and abilities to be mastered, even though they vary in the amount of learner support that is provided and the degree of collaborative activity required. Problems can be defined as “questions rose for inquiry, consideration, or solution”. Instructors facing problem design for their courses attempt to craft problems to support competency development, thus trying to anticipate the “problems in solving the problems”, i.e. facing students with exercising most of the potential difficulties they would find in performing realistic work activities. This can be approached from the experience and sound knowledge of the instructions about the topics to be taught, self-‐reflecting on potential difficulties and pitfalls. In some disciplines, it is easy to find problem collections in textbooks or on-‐line learning resources that can be used as a form of sedimentation of practical experience in proposing and evaluating problems. However, there are topics or disciplines for which few or fragmented problems collections are available, and in general problem collections do not provide hints on the kind of learning difficulties and detailed topic coverage of each of the problems they contain. In those cases, an empirical approach would be helpful to continuously improve and evolve problem collections. Empirical data on problems faced by students can be gathered from the assignments in previous courses. The careful examination of assignment solutions given by students is the best source of evidence for devising new problems or updating existing ones, if we assume that student cohorts are reasonably homogeneous from one year to the next. Human computer interaction (HCI) is a multi-‐disciplinary area of study that is essential in the education of engineers dealing with the construction of man-‐machine interfaces (Rozanski and Haake, 2003). One of the key competencies to be acquired in HCI is usability evaluation. Usability evaluation requires in general analysis skills and critical thinking, as usability problems are often a matter of degree, and knowledge on usability is described in terms of generic rules (usability 80
guidelines), principles or heuristics that require judgment and practice to be mastered. There exist various techniques for evaluating usability depending on available resources (time facilities and resources), evaluator experience, ability and the stage of development of the software under review (Hartson, Andre and Williges, 2001). It seems apparent that problem-‐based approaches to instructional design may be adequate for teaching usability evaluation. However, such approaches require a carefully devised set of problems that provide the required progressive scaffolding (Simons & Klein, 2007). Skov and Stage (2005) reported a study comparing problems found by students using a conceptual tool with students not using it and with the evaluation outcome of the teachers. The use of the tool resulted in more problems found by students, which supports the idea that additional scaffolding elements are required for usability evaluation. The elaboration of case collections for usability engineering has been approached by Carrol and Rosson (2005). These are comprehensive cases that fit project-‐based education, but there is a need to understand and learn to apply the concrete guidelines and heuristics related to expert-‐based usability evaluation, as these can provide detailed insights on how students face usability problems. This paper reports preliminary results of an ongoing comprehensive study on problems found by students when approaching inspection methods for usability evaluation, concretely, heuristic evaluation. Heuristic evaluation is a problem-‐oriented usability evaluation method (Nielsen, 1992). In its initial proposal by Nielsen and Molich (1990), it was found that it served to identify 55 to 90 percent of the known usability problems user interfaces, concluding that heuristic evaluation was a cheap and intuitive method for evaluating the user interface. Heuristic evaluation has an additional interesting property in the educational context: it forces students to classify usability problems, assess their importance and argument why they qualify as such. Consequently, the analysis of records of student heuristic evaluation has the potential to uncover underlying false assumptions, misunderstandings or in general difficulties in acquiring user interface evaluation abilities. The rest of this paper is structured as follows. Section 2 describes the context of the case reported here and the data gathering procedures. Section 3 provides the results of evaluating a small sample of users and discusses these preliminary findings. An example of instruction design from the analysis of assignment data is provided in Section 4. Finally, conclusions and outlook is provided in Section 5.
2. Context and data gathering The ACM/IEEE/AIS curricula recommendations for Computer Science include 8 core hours of Human-‐Computer Interaction, which is concerned with the required skill of “knowing how to create a usable interface and testing the usability of that interface”. In the detailed topics related to HCI, the recommendations include “evaluation without typical users”, including guidelines, heuristics and expert-‐based analysis. While user testing is considered the most reliable way of evaluating user interfaces, teaching guidelines and heuristic evaluation have the benefit of not requiring students to be provided with an observational setting, so that distance students are able to exercise that kind of evaluation. Further, such kinds of evaluations do not rely on the availability of users for testing, but on the application of theoretical elements and guides. If these elements are used for summative assessment of students, the student’s responses can be evaluated rather objectively by instructors. The context of the present case was an elective course on Human Computer Interaction at the last year of a four-‐year degree in Computer Science. The authors had been teaching the course since 2004 following a continuous assessment method. The course starts with an HCI fundamentals module, followed by a module on user interface design and then a usability evaluation module. 81
Students are taught about user testing, but also other methods including heuristic evaluation. One of the assignments included in the continuous assessment presents the students with concrete Web sites for heuristic evaluation, following Nielsen’s heuristics and rating scales. Students have previously exercised the technique at an heuristic evaluation lab, and they are equipped with knowledge on guideline-‐based assessment as a supplementary tool6. The users have to report on problems found as exemplified by the Table 1 entry. Table 1. Categories for problems, severity and error description in problems found. 0
Severity 1 2 3
VSS
X
UCF
Category
4
Error description
The Web site is too much interactive Some pages linked from the homepage have no option X to go back or this option is difficult to find.
Categories for problems are the following: visibility of system status (VSS), Match between system and the real world (MSRW), user control and freedom (UCF), consistency and standards (CS), error prevention (EP), recognition rather than recall (RRR), flexibility and efficiency of use (FEU), aesthetic and minimalist design (AMD), help users recognize, diagnose, and recover from errors (HURE) and help and documentation (HD). Hvannberg, Lai-‐Chong and Larusdottir (2008) found no significant differences between using Nielsen’s heuristics and the cognitive principles of Gerhardt-‐ Powals, and no difference was also found in either using a web tool or paper, so we have not initially not considered these variables in the design of the study. The analysis of assignments requires a detailed representation of problems found versus actual problems (as identified by the instructors), an analysis of the appropriateness of the assessment of severity, and the qualitative examination of justifications in the problems found. The data analysis was done by creating a database following the schema depicted in the Fig. 1.
Fig. 1. Database created for data analysis 6
Concretely, they have been introduced at the beginning of the course to guideline-‐based usability analysis using the research-‐based guidelines elaborated by the U.S. Department of Health and Human Services available at: http://www.usability.gov/pdfs/guidelines.html
82
Table Students recorded information on the students evaluated, the academic year in which they took the HCI course, the site they evaluated heuristically and their overall grade in the course (score). Then, each of the problems identified by students is recorded in the problemsFound table, including severity assigned, Nielsen category selected, and the related guideline(s) identified (if any). The instructors filled the Error field, classifying entries in which students failed to justify the reason of the problem, or simply reported a situation that was not actually a usability problem. Problems found that were actual problems are related to the Problems table, which stores the “correct” problems, categories and severity ratings. Matching problem found descriptions was done by the instructions, even though matching problems has been found to be controversial across matching techniques (Hornbaek and Frokjaer, 2008), here the group and criteria are homogeneous, and they are built by the same matcher.
3. Discussion A sample of the problems found by five students (related to the same target web site) was used as a first application of the analysis method. A total of 82 problems were found by the students, of which 31 were correctly identified problems. Despite the apparent high error rate of this figure (below 50%), it represents a common situation, as there is in general a high dispersion in actual problems found, pointing out that there is some barrier for some students even to identify some prominent problems. This suggests general misunderstandings of usability problems, as confirmed by the qualitative analysis of justification reports. For example, the student with Id 5 reported a total of 31 problems, of which only 11 matched actual problems. Nonetheless, from the other 20 problems, 10 of them were incorrect because they are considered redundant statement (see section 4), that is, very related or identical to problems already detected. For example the student detected that there is no a link to the homepage in 4 pages and reported 4 different errors. There were other 3 reported errors that are considered as partially mistakes because they are very vague descriptions of errors or very subjective (and obvious) opinions (see in section 4 ‘vague statements’). Severity assessments in properly identified problems were identical to instructor assessments in only 13 cases, however, relaxing the coincidence in plus/minus one severity point, the figure was 21 out of 31, which represents a reasonable fit given that severity ratings entail a degree of subjectivity associated with the identification of priorities in fixing errors.
4. Elaborating problem statements from data Evidence gathered from student assignments can be used for developing new assignments and also for the development of guided problems that are targeted to raise difficulties found by students in the past. This requires a categorization of mistakes found. In the sample discussed above, errors were classified in three categories: incorrect, redundant and vague statements. Redundant statements entail the repetition of the same problem found in several sections of the Web site. This adds nothing to the heuristic evaluation report and should be avoided. This frequent error category reveals a methodological mistake, which can be avoided easily by emphasizing the unique nature of problem entries in the report. In this case, a clarification about redundancy was included in the heuristic evaluation report given to students, and an example emphasizing that aspect was also included in the case presented at the lab, which is discussed with the tutors. 83
Vague statements in contrast represent a very broad category, including statements that are to some extent correct, but fail in accurately describing the problem form a usability perspective or even use clichés and stereotypes. Examples of these statements are “the page is too interactive” (supposedly referring to the impossibility of avoiding animation, i.e. a lack of user control) or “the consistency of contents and interfaces is poor” (which fails in detailing the concrete inconsistent elements, e.g. navigation structures, general appearance, etc.). Those reported errors that don’t reflect real usability problems are considered incorrect statements. Examples of incorrect statements are “The site is not WAI compliant” or “In page X there is no link to homepage” when it exists. Although statements like the last one can reflect usability problems, they are considered as errors in the assessment of a report on heuristic usability evaluation. Once the errors reported by students have been analyzed, teachers can fine tune the problems (examples and lab practices) to reflect in usability evaluation case studies most common misunderstandings. To do so, found errors can be grouped by heuristic. After explanations of most common errors by heuristic, the students must evaluate examples and counter examples implemented ad-‐hoc as prototypes which reflect those errors. The learning process can be strengthened planning user interface design problems in which students had to reflect explicitly how to deal with that kind of errors.
5. Conclusions and outlook Problem-‐based approaches to instruction rest in the careful design of problems or cases that are used both for tutoring and evaluating students. Some topics lack reliable, mature problem collections that could be used by instructors as a point of departure. In these cases, evidence can be gathered form student assignments involving problem solving, so that new or revised problems can integrate aspects known to have been difficult to master or sources of common errors in their statement and task design. This paper have reported on the preliminary results of that technique applied to gaining insight on student’s difficulties and pitfalls when confronting heuristic usability evaluation. The procedure entailed a detailed analysis of problem report entries submitted by students and their categorization, leading to three broad categories of error that entail different kinds of update of teaching material. Future work will cover a detailed analysis of the database of at least two student cohorts in the HCI course, and a comprehensive account of potential sources of error and the problem design guidelines that follow from them.
Acknowledgements The research is within the framework of the activity of the educational innovation project UAH/EV243, from University of Alcalá.
References Carroll, J. M. and Rosson, M. B. 2005. A case library for teaching usability engineering: Design rationale, development, and classroom experience. J. Educ. Resour. Comput. 5, 1 (Mar. 2005), 3. Hartson, H.R., Andre, T.S. and Williges, R.C. (2001) Criteria for evaluating usability evaluation methods, International Journal of Human–Computer Interaction 13 (4) (2001), pp. 373–410. 84
Hornbaek, K., Frokjaer, H. (2008) Comparison of techniques for matching of usability problem descriptions, Interacting with Computers, 20(6), pp. 505-‐514 Hvannberg, E.T., Lai-‐Chong, E., Larusdottir, M.K. (2008) Heuristic evaluation: Comparing ways of finding and reporting usability problems, Interacting with Computers, (19)2, pp. 225-‐240 Merrill, M.D. (2007) A Task-‐Centered Instructional Strategy. Journal of Research on Technology in Education, 40(1), pp. 33-‐50 Nielsen, J. 1992. Finding usability problems through heuristic evaluation. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (Monterey, California, United States, May 03 -‐ 07, 1992). P. Bauersfeld, J. Bennett, and G. Lynch, Eds. CHI '92. ACM, New York, NY, 373-‐380. Nielsen, J., and Molich, R. (1990). Heuristic evaluation of user interfaces, Proceedings of the Conference on Human Factors in Computing Systems (CHI 90), Seattle, WA, April 1-‐5, pp. 249-‐256. Rozanski, E. P. and Haake, A. R. (2003). The many facets of HCI. In Proceedings of the 4th Conference on information Technology Curriculum (Lafayette, Indiana, USA, October 16 -‐ 18, 2003). CITC4 '03. ACM, New York, NY, pp. 180-‐185. Simons, K. and Klein, J. (2007). The Impact of Scaffolding and Student Achievement Levels in a Problem-‐based Learning Environment. Instructional Science, 35(1), pp. 41-‐72. Skov, M. B. and Stage, J. (2005). Supporting problem identification in usability evaluations. In Proceedings of the 17th Australia Conference on Computer-‐Human interaction (Canberra, Australia, November 21 -‐ 25, 2005). OZCHI, vol. 122. Computer-‐Human Interaction Special Interest Group (CHISIG) of Australia, Narrabundah, Australia, pp. 1-‐9.
85
This document was finished in Cádiz, 13 of April of 2009
ISBN 978-‐84-‐692-‐3450-‐1
86
Methods and Cases in Computing Education
Held in Barcelona (Spain), April 22nd 2009. Published by the Spanish Chapter of the ACM Special Interest Group on Computer Science Education with the collaboration of the Universitat Oberta de Catalunya.
www.uoc.edu
www.sigcse.es
ISBN XXX-‐XX-‐XXX-‐XXXX-‐X
Methods and Cases in Computing Education by Spain ACM SIGCSE Chapter is licensed under a Creative Commons Reconocimiento 2.5 España License.
[this page is intentionally left blank]
Foreword By Juan-‐Manuel Dodero, president of the ACM SIGCSE Spanish Chapter The ACM SIGCSE Spanish Chapter is the chapter of the Association for Computing Machinery (ACM) Special Interest Group on Computer Science Education (SIGCSE) serving Spain. It started operations in 2008. The chapter provides a forum for common problems among educators working to develop, implement and evaluate computing programs, curricula and courses, as well as syllabi, laboratories, learning technologies, and other elements of teaching and pedagogy. The Chapter supports activities complimentary to SIGCSE, the ACM, and other ACM activities in the Spain area. The Chapter is organized and operated for educational and scientific purposes, its aim being to increase knowledge about computing education, as well as to serve as a means of communication for those interested in this discipline. This workshop on Methods and Cases in Computing Education (MCCE) is the second of a series of events intended to the dissemination of the activities of the chapter members. As such, it will publish articles dealing with the joy, pain and hope of our daily teaching and research experiences in computing education. The MCCE workshop thus constitutes a forum open to anyone wanting to contribute to the chapter aims. The birth of the Chapter and the MCCE workshop, have the main objective of contributing to the discussions on the European Higher Education Area held among the Spanish Higher Education community. For the second edition of MCCE, held at Barcelona, a number of contributions were selected after a peer review process carried out by the chapter committee members and renowned international researchers.
i
[this page is intentionally left blank]
ii
Table of contents Experimental Inquiry into Greedy Algorithms ........................................................ 1
J. Ángel Velázquez Iturbide, Antonio Pérez Carrasco
SET (Software Engineering Tutor), a CASE tool to guide the creation of domain and use case models.................................................................................. 7
Sergio Bravo Martín, Francisco J. García Peñalvo, Miguel A. Conde González
Digital Systems Laboratory for Visually Impaired Students.................................. 13
Joaquín Olivares, José M. Palomares, Edmundo Sáez, José M. Soto
Design of an autonomous and cooperative robots laboratory............................. 23
Guillermo González-‐de-‐Rivera, Ricardo Ribalda, Angel de Castro, Javier Garrido
Database design using a web-‐based e-‐learning tool............................................ 31
Josep Soler, Imma Boada, Ferran Prados, Jordi Poch, Ramon Fabregat
The cost of learning and teaching Java in the Bologna process ........................... 41
Camino Fernández , David Díez, Jorge Torres, Telmo Zarraonandia
A High School Educational Platform based on Virtual Worlds.............................. 46
Mariano Rico, David Camacho, Xavier Alaman, Estrella Pulido
Comparing a fully online course to a blended one: the case of compilers............ 52
Salvador Sánchez Alonso, Daniel Rodriguez García, Robert Clarisó Viladrosa
Learning Engineering by Modeling a Guitar Effects Pedal with FPGAs ................ 61
Joaquín Olivares, José M. Palomares, José M. Soto, Juan C. Gámez
Using IMS-‐LD Standard to Support Learning in Teaching ICTs in Industrial Design Engineering............................................................................................... 71
Rocio Garcia-‐Robles, Fernando Díaz-‐Del-‐Río
Devising instruction from errors in students’ assignments: a case in usability engineering education ........................................................................... 79
Elena García-‐Barriocanal, Miguel-‐Angel Sicilia, Salvador Sánchez-‐Alonso, Daniel Rodríguez iii
[this page is intentionally left blank]
iv
Experimental Inquiry into Greedy Algorithms J. Ángel Velázquez Iturbide (1), Antonio Pérez Carrasco (1) (1)
Departamento de Lenguajes y Sistemas Informáticos I, Escuela Técnica Superior de Ingeniería Informática, Universidad Rey Juan Carlos Móstoles, Madrid, Spain {angel.velazquez,antonio.perez.carrasco}@urjc.es
Abstract Greedy algorithms are one of the most common algorithm design techniques. Unfortunately, they are usually taught and learnt in a passive way. In this paper, we propose a novel approach to active learning of greedy algorithms. The approach is based on experimentation with and evaluation of alternative greedy strategies for several problems. The approach is supported by an interactive assistant, named GreedEx. We also report on the results of its use in real lab situations, where we have evaluated the assistant usability and the students’ results.
1. Introduction Algorithms are a core subject matter of Computer Science. It has achieved a high degree of maturity, with most of its contents well-‐established. A number of algorithm design techniques are usually studied, such as divide-‐and-‐conquer, backtracking, dynamic programming, and greedy algorithms. The organization of greedy algorithms in most textbooks (e.g. (Cormen, T.H. et al., 2001), (Horowitz, E., and Sahni, S., 1978)) is not adequate for active learning. The chapter typically identifies the main elements of greedy algorithms, and states the technique as a high-‐level template. Besides, a set of representative problems is solved (we have cited above some of the most common). For each problem, an optimum greedy strategy is identified and stated recursively. Then its optimality is proved. Finally, the algorithm is coded iteratively and its time complexity is analyzed. This organization exhibits the following learning difficulties: •
Design of an optimal greedy strategy. It is easy for some simple algorithms (e.g. the coin changing problem), but it is much more demanding for others. To illustrate it more vividly, it is not realistic to expect from a student to design Dijkstra’s or Kruskal’s algorithm.
•
Coding a greedy algorithm. Most textbooks provide a high-‐level template. Greedy algorithms have the same semantics as the template, but their code is unique for each algorithm. Furthermore, some algorithms do not even fit this high-‐level template.
•
Proving the optimality of a greedy strategy. Most proofs are either by contradiction or by reduction, techniques that students are not very familiar with.
In summary, despite the apparent simplicity of greedy algorithms, their learning objectives are quite demanding. As a consequence, the instructor commonly gives lectures in a passive way, hardly letting place for active learning. On the student side, most problems solved with greedy algorithms are learnt by rote. In this extended abstract, we propose a new approach to active learning of greedy algorithms. In the second section, we introduce our approach, based on experimentation with and evaluation of alternative greedy strategies for a given problem. The third section describes our experience in using this approach in laboratories. Finally, we summarize our findings and outline future work. (A full version of this extended abstract will contain more elaborated version of every section. In 1
particular, we will describe support the assistants provide for active experimentation, will give a more elaborate analysis of the groups’ outcomes, a more extensive discussion and recommendations for future experiences, and related work.)
2. Active Learning of Greedy Algorithms by Experimental Inquiry In order to overcome the learning difficulties described above, we made an analysis of the different elements of greedy algorithms. We were especially interested in identifying elements that provided opportunities for active learning. We finally concluded that the key decision (and therefore most promising candidate) was the choice of an optimal strategy. Surprisingly, this decision taking is hardly addressed explicitly in textbooks. The only problem where a discussion involving suboptimal strategies can be found is the knapsack problem (e.g. (Horowitz, E., and Sahni, S., 1978)). Here, three strategies are typically considered, namely increasing order of weight, decreasing order of benefit and decreasing order of rate benefit/weight. We describe in the following subsection how to experiment actively with greedy strategies. A brief description of interactive assistant we developed to aid in experimental inquiry can be found elsewhere (Velázquez-‐Iturbide, J.Á., Pérez-‐Carrasco, A. et al., 2008). 2.1. Experimental Inquiry into Greedy Strategies We use in the article the activity selection problem (Cormen, T.H. et al., 2001), given that it is simple but not straightforward to solve. We may state it informally as follows. Given a set of n activities, each one with a start time si and a finish time fi, we seek to select a maximum-‐size subset of non-‐overlapping activities. For instance, given the set of activities in Table 1, the subset composed of activities {3,8,2} is a valid solution, while subset {9,5,4,2} is a maximum-‐size solution. Table 1. An instance of the activity selection problem. i
0
1
2
3
4
5
6
7
8
9
10
si
13
9
29
3
26
13
1
17
10
1
13
fi
15
24
30
7
28
20
6
27
29
13
15
The interesting issue here is trying to discover whether there is an optimal greedy strategy that solves the problem. Firstly, we should try to imagine as many candidate greedy strategies as possible. For instance, we may consider the strategies consisting in selecting activities based on the following nine criteria: •
Random.
•
Activity index in increasing/decreasing order.
•
Start of activity in increasing/decreasing order.
•
Finish of activity in increasing/decreasing order.
•
Duration of activity in increasing/decreasing order.
Of course, the first three strategies are no serious candidates to optimal strategies, but for the other six the choice is not obvious. If we experiment by applying the nine strategies to data contained in Table 1, we obtain the results in Table 2. These results allow us to discard the seventh and ninth strategies. We should now experiment again with the seven remaining strategies over new input data. (Although the first three candidates passed this first filter, they will likely drop soon.) 2
Table 2. Result of applying different strategies. Strategy
Activities selected
# activities
Random
[9, 4, 5, 2]
4
Index, increasing
[0, 2, 3, 4]
4
Index, decreasing
[9, 7, 2, 0]
4
Start time, increasing
[6, 1, 4, 2]
4
Start time, decreasing
[2, 4, 5, 3]
4
Finish time, increasing
[6, 0, 7, 2]
4
Finish time, decreasing
[2, 8, 3]
3
Duration, increasing
[2, 0, 4, 3]
4
Duration, decreasing
[8, 6, 2]
3
Performing as many times as necessary this experiment, we will reach a state where only those feasible strategies will survive. Following our example, we successively used five data sets and obtained the results summarized in Table 3. We only include the number of activities selected in each case. Table 3. Results over different input data. Strategy
1st run
2nd run
3rd run
4th run
5th run
Random
4
3
2
-
-
Index, increasing
4
3
3
2
-
Index, decreasing
4
3
3
1
-
Start time, increasing
4
3
3
1
-
Start time, decreasing
4
3
3
3
3
Finish time, increasing
4
3
3
3
3
Finish time, decreasing
3
-
-
-
-
Duration, increasing
4
3
3
3
3
Duration, decreasing
3
-
-
-
-
Notice that there are three remaining strategies. We could go on experimenting with new input data, or stop and try to formally prove the optimality of the three remaining strategies. Table 3 shows three candidate strategies to optimality; however, it must be noticed that one of them (namely, increasing order of duration) is not optimal.
3. Experience Several years ago we started the development of three assistants for different greedy algorithms: the knapsack problem, the activity selection problem, and the minimum cost spanning tree problem (including Prim’s and Kruskal’s algorithms). The maturity of these assistants differs. Assistants for the knapsack problem and the activity selection problem are mature programs, while the assistant for the minimum cost spanning tree problem is a working prototype. The usability of the two first assistants was evaluated by experts 3
(i.e. the instructor) and also by students in lab sessions. They gave us feedback about user acceptance, evaluation of the main features, and open suggestions. The results of usability evaluations were highly positive, and also allowed us to enhance their user interface and functionality. More information about the knapsack assistant and usability results can be found elsewhere (Velázquez-‐Iturbide, J.Á., Lázaro-‐Carrascosa, C.A., et al., 2008). We are currently integrating them into a single interactive assistant, called GreedEx. We use this name in the rest of the extended abstract. In the following subsections, we focus on the last evaluation. We describe the characteristics of the assignment and the outcomes of students with respect to the task assigned. 3.1. Protocol The laboratory evaluation was performed within the lesson on greedy algorithms. This chapter is a part of the course “Design and Analysis of Algorithms”, mandatory course for students of Computer Science. The evaluation was held in January 2009 and consisted in two sessions, being each session two hours long. A total of 24 students participated. Student work could be made individually or in pairs, but the opinion questionnaire that had to be made individually. Students were given the assignment statement, the assistant, a report model and an opinion questionnaire. Before the first session, the instructor had given the basics of greedy algorithms. He also had used GreedEx to illustrate the knapsack and the minimum cost spanning tree problems. In the first session, students had to perform three tasks: 1. Use the GreedEx interactive assistant to determine which of the strategies offered are optimal for the activity selection problem. 2. Fill and deliver a short report, following the model provided. 3. Fill and deliver the opinion questionnaire about GreedEx. Between both sessions, the instructor reviewed a number of relevant concepts, namely, hypothesis, experiment plan, refutation, counterexample, empirical evidence, and inductive and formal reasoning. At the beginning of the second session, the instructors identified which strategies were optimal, namely increasing order of finish time and decreasing order of start time. Students had to work within the same groups as in the first session. Depending on their findings in the first session, students had to make different tasks. For every strategy they had wrongly identified as optimal, they had to find any counterexample. For every strategy they failed to identify as optimal, they had to review their past experiments and find out why they failed to identify it. Their task had to be elaborated in a short report and delivered during the session. 3.2. Results The first session was performed by 31 students organized in 18 groups (13 pairs and 5 individuals). However, in the second session only 24 students participated, grouped in 11 teams (9 pairs and 2 individuals). We are interested in the strategies identified as optimal by the students. Table 4 shows the number of groups that proposed each strategy. It is not surprising that the optimal strategies are scored high. In fact, one of them (increasing order of finish time) was proposed by all the teams but one. A high number of groups (14) identified the strategy of increasing order of duration. This is not surprising, as it is a suboptimal strategy that delivers good results, as we showed in Section 2.1. Other suboptimal strategies 4
obtained zero or two votes. Table 4. Number of proposals per strategy. Strategy
# proposals
Random
0
Index, increasing
6
Index, decreasing
6
Start time, increasing
0
Start time, decreasing
14
Finish time, increasing
17
Finish time, decreasing
2
Duration, increasing
14
Duration, decreasing
0
There are two most surprising results. First, one of the optimal strategies only scored 14. Second, a relatively high number of teams (6) proposed the two strategies based on indices. We also are interested in analyzing how the groups performed in each independent session. With respect to the first session, we have the following results: •
All the groups but two only document between 2 and 5 runs to justify their selection. The other two groups run 9 and 13 input data, respectively and chose the correct strategies.
•
Two expected outcomes were: a group providing a reasoned rationale (either correct or incorrect), and a group without rationale. Other cases were: a group giving a meaningless rationale, a group giving a rationale dependent on a case (e.g. the list of activities being arranged in a specific ordered) or specific to each input data. Up to 5 groups provided a second optimization criterion to justify their selection of an optimal strategy. It seemed that they only could accept the existence of a single optimal strategy.
•
Some groups made wrong proposals based on a misunderstanding of the task to solve or due to previous misunderstandings. However, other groups were inconsistent in the process of analyzing the results of their runs.
There is a variety of groups that did not attend at the second session. Two groups had marked high in their first session, and four had performed poorly. With respect to their second task, most of the groups performed good.
4. Conclusions and Future Work Despite the apparent simplicity of greedy algorithms, it is difficult to learn them actively. We have presented in the paper a novel approach to active learning, based on experimentation with and evaluation of alternative greedy strategies. Consequently, the work here presented is a contribution to experimentation and the scientific method in CS education. Our approach is supported by the GreedEx interactive assistant. GreedEx has been evaluated for usability in real lab situations, having obtained high scores from students as well as useful information to enhance them. We have also reported on the successful performance of students 5
in their inquiry task. We plan to extend our work in several directions. Firstly, more problems can be integrated in GreedEx. Secondly, we are designing a fixed format for reports, which will also be supported by Greedex. Finally, we should make more emphasis in the future to proofs of optimality by students.
Acknowledgments This work was supported by project TIN2008-‐04103/TSI of the Ministerio de Ciencia e Innovación.
References Cormen, T.H., Leiserson, C.E., and Rivest. R.L. (2001). Introduction to Algorithms. The MIT Press, 2ª ed. Denning, P. et al. (1989). Computing as a discipline. Comm. of the ACM 32, 1, 9-‐23. Horowitz, E., and Sahni, S. (1978). Fundamentals of Computer Algorithms, Pitman. Velázquez-‐Iturbide, J.Á., Lázaro-‐Carrascosa, C.A., and Hernán-‐Losada, I. (2008). Asistentes interactivos basados en la taxonomía de Bloom para el aprendizaje de algoritmos voraces. IEEE Revista Iberoamericana de Tecnologías del Aprendizaje, accepted. Velázquez-‐Iturbide, J.Á., Pérez-‐Carrasco, A., and Urquiza-‐Fuentes, J. (2008). Active learning of greedy algorithms by means of interactive experimentation. In Proceedings of the 14th Annual Conference on Innovation and Technology in Computer Science Education, ITiCSE 2009, accepted.
6
SET, a CASE tool to guide the creation of domain and use case models in an introductory Software Engineering course Sergio Bravo Martín (1), Francisco J. García Peñalvo (1), Miguel A. Conde González (1) (1)
Universidad de Salamanca, Facultad de Ciencias Plaza de los Caídos s/n, 37008 Salamanca (España) {ser, fgarcia, mconde}@usal.es
Abstract The idea of using CASE (Computer Aided Software Engineering) tools in education as an interactive learning has been emerging for serveral topics in computer science. The learning process proves to be more effective, rapid and even persistent. This paper presents a CASE tool named Software Engineering Tutor (SET), which main aim is to improve the students’ knowledge in Software Engineering field, specifically to guide them in the domain and use case models construction. Besides, this tool offers a repository of case studies, trying to make an effort to share experiences around the university and professional community. Our experience with this tool, specially at the workshops of the Software Engineering subject during the last academic year, shows that SET is an useful tool for learners of such subjects and from student's very instructive. Moreover, it has become a key element of support for the continuous assessment introduced in the course.
1. Introduction Software Engineering, which traditionally has appeared like a discipline of Computer Science, is being considered in recent years as an entity separate curriculum, but with deep roots in the Computer Science and Mathematics. It offers methods or techniques for developing and maintaining quality software that solve all kind of problems. There are many CASE tools that provide support to Software Engineering and contribute greatly to increase productivity in software development reducing the cost in terms of time and money. These tools are applied in all aspects of the lifecycle of software development such as planning, analysis, design, project documentation (textual and graphical), automatic code generation and error detection, and so on. This paper presents a new CASE tool named Software Engineering Tutor (from now on SET), designed to provide support in the early stages of the lifecycle. It particularly focuses attention in requirement engineering and analysis stage, with the facility to create use cases and domain models respectively. But the elements that differentiate SET from other tools are the innovative teaching approach and the self-‐training for the software engineer, due to a modeling wizard that guides the user step by step in the building models. SET has been developed by a Final Project at the Computer Science Department of the University of Salamanca, and specially used in the practical part of the Software Engineering subject at the third course of the Computer Science Degrees. The article is divided in the following sections: Section 2 gives a review of the context subject and the continuous assessment process introduced since the academic year 2005-‐06, and how SET fits in this strategy. Section 3 describes functional characteristics of SET. Finally, we present the conclusions taken from this case study. 7
2. Software Engineering subject: context and assessment process Software Engineering has great important in the curriculum of Computer Sciences Engineering because it is essential to have strong knowledge about developing software and all the stages of its lifecycle, beginning with the necessity of building a system, passing throw the implementation and ending with the software maintenance. This subject shows to the students a set of principles that are regularly and systematically applied in designing and constructing economically viable computer software tasks. In order to understand the different topics is necessary that the student will be capable of performing a job for reflection, assimilation and practice of different underlying topics of the program subject. Encouraging these disciplines and considering that in most cases students apply every effort only to pass, it becomes necessary to apply a methodology for continuous assessment. 2.1 General concepts of the subject The course comprises 60 hours (45 theoretical hours and 15 lab hours) and tries to focus attention on the following topics:
Lifecycle and process requirement elicitation and documentation.
Analysis and design methods and notation.
Modularity, software architecture, and software reuse principles (design patterns and reusable solutions perfectly valid).
The presentation of these topics emphasizes abstraction as the fundamental technique for understanding and solving problems (Wasserman, 1996). Somewhat, this is the main problem that students suffer at this course, because of the experience of the analyst role is very important and there is not a scientific method or technique to complete the early stages of the lifecycle of software development. This handicap is exacerbated further in Engineering Degrees in those object modeling is taught in first courses. The traditional way to perform the practical part and assimilate the knowledge required by this subject is developing a small engineering project (Chamillard, 2002), at least as far as the analysis and design stages. However, it is necessary to supplement the practical part with a series of workshops (Garcia, 2004) that cover the following topics:
one workshop devoted to the entity-‐relationship model, in order to review conceptual data modeling principles,
two workshops devoted to introducing the object-‐oriented analysis using Unified Modeling Language (OMG, 2004) as the modeling language (from now on UML), in order to build domain models (class diagrams) and,
last workshop devoted to introducing the basic principles of use case diagrams, using again UML (Rumbaugh, 2005), and like a first approximation to requirements engineering.
According to this idea, SET aims to support young students in the stages of requirement engineering and analysis, particularly in the construction of domain and use case model covered in the last three of the four workshops planned for the course. 2.2 Assessment process In addition to the traditional evaluation system, students can optionally choose a continuous 8
assessment, in which attendance and active participation play an important role. The implementation of continuous assessment, in the context of this subject, is a major challenge, therefore should be implemented on two large groups with approximately 100 students each one (Garcia, 2008). This evaluation system provides continuous on-‐line information about subject that can contribute to improve or even redirect the process of student learning. However, teachers need the tools and suited methods to know the feedback on the degree of learning of student during the course. This is one of the most important benefits of using SET in order to support the process of continuous assessment, through the homogenization of the reports submitted. 2.3 Introducing SET in the learning and assessment process In order to apply a methodology for continuous assessment at the subject, the teachers need agile and effective mechanisms to obtain the learning degree of students over the course. During the last academic year, the subject of Software Engineering has used two support tools in the learning and assessment process: 1. Studium (supported by Moodle), an online virtual campus for the subject, with the following resources:
Contents described at the program subject and presented at attending classroom.
Forums to control the students’ participation over the course.
Forms to collect the reports required at workshops and voluntary exercises.
2. SET (Software Engineering Tutor), a learning tool with the following competences:
Supporting the teacher at attending classroom to present theoretical concepts about object modeling techniques.
Guiding the software engineer (or student) in the use case and domain models creation.
Normalizing the practical workshop or exercises reports.
3. Functional description of SET The key features of SET, currently in version 1.0.7, focus primarily on the following topics:
a modeling wizard as a mechanism to support the construction of use case and domain models,
a standard mechanism to make personalized and normalized reports,
a central repository of such case studies,
compatibility with other CASE tools using XML Metadata Interchange (from now on XMI) and desktop programs, and
user interface based on different views of the model under construction.
3.1. The modeling wizard The original idea of Software Engineering Tutor is mainly to introduce the student (or software engineer) at the requirement engineering and object-‐oriented analysis stage by the use case and domain models construction. Both models are built graphically using UML diagrams. However, its 9
contribution in the real world of CASE tools lies in their orientation on training and instruction in building such models using an integrated modeling wizard. This intelligent wizard makes SET a unique tool. The modeling wizard is a dialog box that allows the user to navigate freely through a set of steps that guides the process of building models. All strategies used to design the wizard (i.e., the identification of conceptual classes based on lists of categories) are taken from the literature (Larman, 2002). Regarding the domain model, the techniques used for the design of the wizard are the following:
Identification of conceptual class (using category list).
Identification of associations.
Identification of attributes.
Identification of superclasses and subclasses.
Identification of whole-‐part relationships.
In addition to Larman’s techniques, it is also possible the identification of conceptual classes using the method describe at (Coad, 1990). The steps of the use case model wizard are also based on Craig Larman indications too. Each step is presented in a concise way and with the necessary controls, so that users can complete perfectly. Moreover, there is the option to extend the information on the current step, with detailed instructions (and examples) on how to complete it.
Fig. 1: Domain modeling wizard The wizard is fully associated with the main frame of the application, so that both workspace environments will work on the same data. In this way, the effects produced by actions in the wizard will be instantly visible at the workspace. 3.2. Normalized reports The tool allows to the user printing reports of a project (previously saved) and exporting them to Portable Document Format (PDF). In addition, it is able to create own report types. This functionality offers to the teachers the possibility to normalize the reports at the practical workshops and even in the volunteer exercises delivered. In this way, the evaluation of the reports 10
is more agile and at the same time is possible to ensure the originality of the work and, for example, the detection of plagiarism. 3.3. Central repository Any tool that provides a teaching approach requires a basic knowledge and useful learning support. In our case, SET provides to the university community a wide range of well-‐known case studies that serve as examples and support for students. According to this approach, SET uses the template concept as a default case study (or standard model). It provides to SET the power to build new models from existing ones. In order to generalize the use of the tool, and particularly the availability of the templates catalog, the Computer Science Department of the University of Salamanca has created a virtual space on Internet (available at http://set.usal.es), with a central repository of a set of standard templates with solutions to well-‐known case studies. These templates can be viewed and downloaded directly from the repository without leaving the workspace. In addition, the repository is ready to interact with it only registered users.
Fig. 2: SET workspace with the four views 3.4. Compatibility SET can be exported according to the XMI standard (XML Metadata Interchange) for exchange diagrams (OMG, 2007). In this way, the tool does not become a close application, but it is supplemented with other CASE tools that provide support in other stages in the software development lifecycle. It could be said that, although this tool provides the user on everything needed for the construction of diagrams related to the domain model and use cases, the main purpose of SET is not to draw diagrams, but tutoring and assisting in the creation of these models. 3.5. User interface based on different views The workspace of the case tool is divided into four views that provide different perspectives of the 11
model under construction (see Fig. 3): model (elements model in a tree view), diagram (current model in diagrammatic form), properties (properties of the selected element of the current model) and console view (text read-‐only with a history of all relevant actions from the current model). 4. Conclusions SET aims to be the germ of a new type of CASE tools for the training of future software engineers. The learning process is marked by a complete and proven wizard that guides the construction of domain and use cases models. One of the benefits on the assessment process after incorporating the tool on practical workshops on the subject of Software Engineering has been the unification of all documents by the automatic generation of reports functionality. Also, the initiative of the case studies central repository not only expands the possibilities of using the tool but also sharing other cases made by other members of the academic community or professionals. Moreover, due to the distributed nature of this case tool, we find the possibility of working with the client application in offline mode. Finally, the compatibility with the UML and XMI standards allows that the SET models can be used in other case tools or desktop applications.
Acknowledgment This work is partially supported by the Regional Ministry of Education of Junta de Castilla y León through the project GR47.
References Chamillard, A.T. , Braun, K.A. (2002). The software engineering capstone structure and tradeoffs, In Proceedings of the 33rd SIGCSE Technical Symposium of Computer Science Education— SIGCSE’02, pp 227–231. Coad, P., Yourdon, E. (1990). OOA Object-‐Oriented Analysis, Prentice-‐Hall García, F.J. and Moreno, M.N. (2004). Software Modeling Techniques for a First Course in Software Engineering: A Workshop-‐Based Approach. IEEE Transactions on Education, Vol. 47, No. 2. Garcia, F.J., Conde M.A., Bravo, S. (2008). Continuous Assessment in Software Engineering, In Proceedings of the Methods and Cases in Computing Education, MCCE ‘08, Salamanca, Spain, pp 41-‐46. Larman, C. (2002). Applying UML and Patterns: An Introduction to Object-‐Oriented Analysis and Design and the Unified Process, 2nd Edition, Prentice Hall OMG (2004). Unified Modeling Language: Superstructure. Version 2.0. Object Management Group Inc. Document formal/05-‐07-‐04 [on line]. Available on: http://www.omg.org/cgi-‐ bin/doc?formal/05-‐07-‐04 [Last visit, sep-‐2008] OMG (2007). MOF 2.0/XMI Mapping, v2.1.1. Object Management Group Inc. Document formal//2007-‐12-‐01 [on line]. Available on: http://www.omg.org/docs/formal/07-‐12-‐01.pdf [Last visit, sep-‐2008] Rumbaugh, J., Jacobson, I., Booch, G. (2005). The Unified Modeling Language. Reference Manual. 2nd Edition, Addison-‐Wesley Shlaer, S., Mellor S. J. (1988). Object-‐Oriented Analysis: Modeling the World in Data. Yourdon Press Wasserman, A. (1996). Toward a discipline of software engineering. IEEE Software, Vol. 13, 23–31. 12
Digital Systems Laboratory for Visually Impaired Students Joaquín Olivares, José M. Palomares, Edmundo Sáez, José M. Soto Department of Computer Architecture. University of Córdoba. Campus Rabanales. 14071. Spain {olivares,jmpalomares,edmundo,jmsoto}@uco.es
Abstract This paper describes how the practical sessions of the Digital Systems Laboratory within the Computer Science Degree have been adapted to allow a visually impaired student to take part in the practical sessions. Regular students use a computer-‐-‐aided design tool (OrCAD) for digital design in their practical assignments. This work shows how the use of special instrumentation allows visually impaired students to work with regular students in the same lab, where the CAD tool is installed. The teaching methodology and the obtained assessments are introduced here. Some specific practical materials have been designed and they are described in this work; the design of a special buzzer is also presented.
1. Introduction The subject known as Computers Structure and Technology is scheduled for the second semester of the first academic year in the Computer Sciences Degree in the University of Córdoba, Spain. It consists of 45 theoretical hours, 15 hours of exercises, and 30 hours for practicals in labs. Four theoretical hours a week are given, including theory and exercises, while two practical hours a week are given in labs. The course lasts for 15 weeks. This information is all summarized in Table 1. Table 1. Course description Lectures (4h./week)
Week Laboratory (2h./week)
1. Introduction. General overview
1
Lab. equipment and safety
2. Information representation
2
CAD tool introduction
3. Boole Algebra. Logic gates
3
Simulating logic gates
4
Minimisation
5
NAND, NOR synthesis
5. Combinational design
6
Combinational I
6. Combinational logic circuits
7
Combinational II
8
Adder/Subtracter
4. Logic functions. Minimisation
7. Digital arithmetics 8. Digital artihmetics circuits
9 10 11
9. Sequential systems
12 13
10. Sequential circuits
14 15
Arithmetic Logic Unit (ALU) Counters RAM memory Laboratory examination
The main objective is to introduce the basic concepts underlying the digital systems, as well as the instruments used to design digital electronic circuits. In the laboratory, the students use the 13
OrCAD tool to design simple combinational, arithmetic, and sequential circuits. A visually impaired student (VIS) enrolled in this subject. He was not able to perform the lab sessions with the CAD tool due to his impairment. Thus, an alternative method was needed. The goal of this paper is to describe this alternative method. This particular experience is to be considered as a starting point for teaching Digital Systems to visually impaired students (VISs).
2. Course Description of the Practical Sessions Below, the proposed practicals are described:
1st Week Laboratory equipment and safety. In this session, the lecturer introduces the practical sessions, shows the lab to the students, explains the safety rules and informs the students about the emergency exits. 2nd Week CAD tool introduction. The second session is used to teach the students some concepts about the operating system (OS), their OS accounts, and to perform an introductory tour about OrCAD, showing the main characteristics of this tool. 3rd Week Simulating logical gates. Students learn how to design a basic circuit using logical gates, input and output ports, and wires. The process to compile, stimulate, and simulate a circuit is also shown. How to understand the graphical simulation is also explained. 4th Week Minimisation. Simple combinational problems are simplified using Karnaugh maps. Afterwards, students implement the solution in OrCAD and simulate it to check its validity. 5th Week NAND and NOR Synthesis. Students apply the universality of the NAND and NOR logic gates. 6th Week Combinational I. To familiarize students with real cases, simple problems are described. Students should first obtain the truth table, perform Karnaugh simplification, obtain the logical equation that represents the solution, turn the equation into a schematic design, compile it, and finally, stimulate and check that the simulation is correct. 7th Week Combinational II. More complex problems are introduced in this session. These problems require the use of buses. 8th Week Adder/Subtracter. In order to introduce the students to binary arithmetic, a 1-‐bit full adder (FA) is designed. Then, students use this component to design a 4-‐bit FA. Next, using two's complement, students design a 4-‐bit subtracter using the adder which was previously designed. Concepts of hierarchical designs are introduced. 9th-‐10th Week Arithmetic Logic Unit (ALU). A 4-‐bit ALU capable of performing 8 different operations, is implemented within this practical session. 11th-‐12th Weeks Counters. The design of a modulo-‐6 up/down counter is proposed to introduce students into the sequential systems. Synchronous and asynchronous signals are studied. 13th-‐14th Weeks RAM Memory. Students are asked to design a 4 x 3 RAM memory, with one bidirectional 3-‐bit data bus. It provides the students with the concepts of memories, bidirectional ports, and tri-‐state buffers. 15th Weeks Laboratory examination. Students are asked to design, implement, and simulate one exercise based on the previous sessions. 14
3. A visually impaired Student University of Córdoba informed the professors a few months before the course started that a student called Rafael (Rafael allowed the use of his name and photographs within the academic scope.) enrolled in the subject described above. He presents a visual impairment that consists in just 12% lateral vision in the right eye, while the left eye is totally blind. He is able to read Braille proficiently. He is able to recognize different colours presented in large lines. However, he needs to approach his face to the drawing very closely. This impairment prevents him from performing the practical sessions with the OrCAD tool. Thus, a different approach was needed. This approach should give Rafael similar knowledge to that acquired by the other students. First of all, a search in the scientific literature for different strategies for teaching Electronics, Digital Systems, or similar subjects to VISs was carried out. A small amount of works in this field were found. Some of them, which are the most representative ones, are stated below. In (Graham et al., 2007), an initial study on interface design for VISs is presented. In this work from the Computer Science at Ulster and Electronics at York, they obtain one main conclusion: touch is best for orientation in schematics. They also recommended suppressing superfluous information. However, no experimental results are shown in the article. (Bel and Bradburn, 2008) present a basic study about materials and accessibility, based on a questionnaire distributed among teachers. Results suggest that professors show a lack of technical knowledge that prevents them to use the technical material properly. In (Harrison et al., 2008), the authors present a preliminary work to collect information for a future Virtual Learning Environment (VLE) tool. This VLE tool was expected to be an interesting starting point for adapting the practices for Rafael; however, current VLE platform is not available for severe VISs or blind people. (Rodríguez-‐Ascaso et al., 2008) show a work in progress about personalized support to students with disabilities based on some educational guidelines for higher education. Conclusions are not yet obtained, and thus, those guidelines have been used just as suggestions. All these works in progress about accessibility in education for students with disabilities are theoretical proposals without any experimental results. Currently, interface design for VISs predominantly includes Tactile User Interfaces (TUIs) or Audio User Interfaces (AUIs) (Benyon et al., 2005). Several authors have stated the importance of the tactile abilities for blind students (Tubiana et al., 1984), (Rogow, 1987), (Rogow, 1990), (Mommers, 1975). Other authors (Fricke and Baehring, 1994), (Huang al., 2004), have made use of different instruments to control systems using audio interfaces. Thus, the proposed solution was to substitute the practical sessions using the CAD tool with other using real lab instrumentation which could be controlled by means of the hearing and touch. On the other hand, in order to make the integration of Rafael with the rest of the students easier (Stovall and Sedlacek, 1983), the instrumentation to be used is taken to the lab where those students are working. Fig. 1 depicts this situation.
4. Practical Material and Instrumentation As it has been stated previously, Rafael is able to read Braille. This fact is quite common in most visually impaired students (Gray and Wilkins, 2005), and thus, most of the subjects previously translated to Braille are available for new students. However, in this case, after a deep search helped by ONCE (Spanish National Organisation for the Blind), there were not found any VIS who had attended a Digital Circuit lab within Computer Sciences Degree in Spain. Therefore, the first task was to translate all the written course material into Braille. All the used diagrams were also embossed and coloured. 15
Fig. 1: Rafael and other students at laboratory. In the search for methods for the adaptation of the assignments for Rafael, different solutions were considered. Two of them have been frequently used in assisting visually impaired people: Windows Magnifying Glass (Pyy et al., 2007) and JAWS Software (Freedom Scientific, 2009). However, they were not applicable within this scope. Windows Magnifying Glass is useful when the visual impairment is not severe. The method described in this work is designed for seriously impaired people, even for blind people. Therefore, Windows Magnifying Glass was discarded. JAWS Software is useful when the impaired person works with textual information. In this case, the electronic designs are represented using schematics. Thus, JAWS Software has not been a great help for this work. After that, other solutions were investigated. Several attempts using a voice synthesizer software capable to read the screen (Barry, et al.1994) with OrCAD design software were tried. However, this produced unsatisfactory results and thus, it was rejected. Finally, it was decided not to use OrCAD software and to adapt the assignments to be able to implement them using physical circuits. Moreover, the fact that the impaired student could work with real devices, instead of with CAD tools, was considered to be very interesting. 4.1.
The Generic Protoboard
VISs use their fingertips to read, to locate elements, etc. They are able to locate chips and to count every pin of them. However, these pins are too close to each other and sometimes they find hard to plug cables attached to those chips. In order to help the tactile guidance of the VIS throughout the chips involved in the implementation of the different assignments, a generic protoboard was used. This protoboard allows the use of different 74LSxxx chips. The chips needed in the design of the solution of the laboratory assignments are plugged in the sockets of this protoboard. Each chip socket has a plastic piece to unplug each chip easily and without damaging its pins. By using this protoboard, pins are guided by wires to separated sockets, much easier to manage by VISs than the standard pins in the chips. 4.2.
Embossed Cardboard of the Chip
Several days before each session, a cardboard with a design of every chip is given to Rafael. This cardboard is designed using Braille for the text and embossed and coloured lines for the electrical connections. Different chips are identified by Rafael, and he situates them close to the protoboard 16
in an order that allows him to remember each one and lets him locate and use the documentation translated into Braille of each chip. 4.3.
Proposed Practical Material and Instrumentation
Standard lab instruments have been used, but as other authors have done (Fricke and Baehring, 1994), one instrument was specifically designed to perform the proposed assignments (the buzzer) and another was adapted to be used by VIS (small modifications on the protoboard). The proposed instrumentation comprises:
A 5V continuous current power supply used for TTL logical devices.
A clock generator device.
A generic protoboard which allows discerning between the pins of a chip by touch. Small modifications have been carried out on the internal connection lines of this protoboard, as well as on the ground and power lines, which are embossed in order to be easily identifiable. To differentiate between them, power lines are coloured in red, while ground lines are coloured in black. If other students are not able to differentiate between colours, the embossed lines could be modified using different textures.
A specially designed buzzer. It consists of one terminal that can be easily connected to any of the protoboard pins in order to perform voltage measure. The buzzer volume can be easily adjustable due to the variable impedance that has been incorporated. A logical 1 activates the buzzer, while a logical 0 produces no sound. The buzzer design is illustrated in Fig. 2a. The device is shown in Fig. 2b.
Cables with connectors for the protoboard.
Some chips from the TTL 74LSxx family. The student is given special instructions about the encapsulation and how to identify the different pins.
It is to be mentioned that all these practical material and instrumentation have been designed and built in a low-‐cost basis because no extra funds were given for this project. The only external body which provided some help was ONCE: a printing device able to print in relief, which was used to print Braille texts and schematics.
Fig. 2, a): The Buzzer design. b) The Buzzer
17
4.4.
Security Issues
With regard to the security issues, they are described to Rafael in the first week of the practical sessions. Rafael's workplace is located close to the exit and out of the way out. Thus, the other students could easily evacuate the classroom in case of emergency. Furthermore, the student situated closer to Rafael would help him in his way out of the lab. The equipment used by Rafael has low voltage and amperage. And therefore, no additional security measures are needed.
5.
Description of the Adapted Assignments for Visually Impaired Students
In this section, the different assignments adapted for VISs will be described. hey have been designed to be feasible for other visually impaired students. The practical sessions are the following: •
1st Week Laboratory equipment and safety. In this session, the lecturer introduces the practical sessions, shows the lab to the students, explains the safety rules and informs the students about the emergency exits. The student with the visual impairment sits in a special table close to the lecturer and to the main exit of the lab. In an emergency case, he should follow the instructions given by the lecturer. Moreover, the student that is closest to the one with the impairment is trained to help him to evacuate the lab if it is needed.
•
2nd Week Lab instrumentation introduction. The student is instructed about the use of the instrumentation listed in Section 4.
•
3rd -‐ 4th Weeks Getting used to the instrumentation and logical gates. This session is used to familiarize the student with the instruments. The student verifies the truth table of the several TTL logic gates. He learns how to stimulate logic gates. Different gates are given to the student and he is asked to identify each of the gates, interpreting the truth table obtained using the buzzer.
•
5th Week NAND and NOR Synthesis. The student applies the universality of the NAND and NOR logic gates simultaneously with his classmates. At the end of the session, he is able to easily identify the logic state of inputs and outputs of the logic gates.
•
6th Week Combinational I. This session is similar to that performed by the rest of the students using OrCAD. He designs the solution before the practical session, and once in the lab, he implements it and checks it.
•
7th Week Combinational II. This session is also similar to that performed by the rest of the students. More complex problems than those proposed in the past session are proposed in this assignment. At the end of the session, the student has achieved the same level of knowledge in digital logic design as the other students, except for the information about OrCAD.
•
8th – 9th Weeks Adder/Subtracter. The student is introduced in the field of digital arithmetic by the implementation of a 1-‐bit full adder. This task is also scheduled to regular students. After that, a 2-‐bit full adder is designed, instead of the 4-‐bit full adder implemented by his classmates. This is due to the higher complexity of the physical designs against simulated designs. However, the knowledge acquired by the student is equivalent. Finally, an adder/subtracter using two's complement is implemented.
•
10th Week Combinational MSI (Medium Scale Integration) Devices I. The design of an ALU requires a great number of connections and components. Therefore, it is not possible for a VIS to tackle with such a design. Instead, the student is asked to design the Logic Unit only, using a 18
74LS151 multiplexer and a function generator to test all the possibilities. •
11th Week Combinational MSI devices II. The student designs simple combinational circuits using a 74LS138 decoder. The technique to use a decoder as a demultiplexer is also introduced.
•
12th Weeks Counters. The student works with a 4-‐bit binary counter (74LS161) and a decade counter (74LS162). Then, he designs an 8-‐bit decade counter using two 74LS161 modules, applying carry propagation.
•
13th Week Registers. In this session, the student works with a 4-‐bit register (74LS194), which allows parallel and serial access, as well as left and right shift. During 12th and 13th sessions, the concepts of synchronous systems, clock edge, and sequential systems are introduced.
•
14th Week Flip-‐flops. In order to understand the functionality of memory elements, a JK flip-‐ flop (74LS112) is used. The four possible inputs of the flip-‐flop are tested. A 2-‐bit asynchronous counter using a JK flip-‐flop is also designed.
•
15th Week Laboratory examination. This session is not necessary, as the student is continuously evaluated.
A comparison between the assignments performed by regular students and those proposed to VISs is given in Table 2. Apart from the practical sessions in weeks 1, 2, and 15, used to get in touch with OrCAD and to examine the students, they must complete eight assignments. In weeks 3 to 8, a VIS solves the same assignments than the other students. In week 9, a VIS implements part of an ALU. Regarding the counter, a VIS designs an 8-‐bit decade counter using MSI circuits, instead of using logical gates as his classmates. At the end, a VIS studies the flip-‐flop as the basic memory element, and uses it to design registers. On the contrary, the rest of the students design a full 4 x 3 RAM memory. While regular students perform 9 assignments (weeks 3 to 14), a VIS completes 10. However, the practical sessions in weeks 10th and 14th are reduced versions of the equivalent assignments for the other students (part of an ALU in week 10th and flip-‐flops instead of RAM memory in week 14th). Thus, it is expected that a VIS is able to acquire a similar level of knowledge as the rest of the students. Table 2. Laboratory course comparison Visually impaired student
Week Other students
Lab. equipment and safety
1
Lab. equipment and safety
Instrumentation introduction
2
CAD tool introduction
3
Simulating logic gates
4
Minimization
NAND, NOR synthesis
5
NAND, NOR synthesis
Combinational I
6
Combinational I
Combinational II
7
Combinational II
8
Adder/Subtracter
Basic logic gates
Adder/Subtracter
9
Combinational MSI I
10
Combinational MSI II
11
Counters
12
Registers
13
Flip-flop
14
19
Arithmetic Logic Unit (ALU) Counters RAM memory
Unused
6.
15
Laboratory examination
Evaluation
After presenting the adapted assignments, the evaluation of Rafael with those assignments is shown. Each practical assignment, previously translated into Braille, was proposed to Rafael at least two weeks in advance. Thus, Rafael prepared the formulas and the resolution of each practical before coming to the lab. The qualification of each practical was obtained using several principles such as attendance to the practical sessions, theoretical development of each practical, implementation (in particular, good organization, cleanness, and tidiness of the design in OrCAD), and finally and most importantly, the correctness of the solution provided. These principles were applied to all the students, both VIS and non-‐VIS. Every student is awarded several points depending on their attendance, on the theoretical development of each practical, on the description of the implementation (taking into account, the organization, cleanness, and tidiness of the implementation of every practical), and above all, on the solution they provide. In order to pass the subject, students have to obtain at least 50% in each of the proposed assignments. 6.1.
Examination Results
According to those principles, Rafael obtained an overall qualification of 9.65 points (out of 10), which is highly remarkable. Rafael was an outstanding student and obtained a qualification grade of “A”. The score for each practical is shown in Tab. 3. There, “Partial Score” stands for the score obtained by Rafael in every practical; every practical is weighted using “Practical Weight” to sum up the final value; “Practical Score” is the value obtained by Rafael weighted in order to compose the “Global Score”. “Practical Score” and “Global Score” are ranged from 0 to 10. In order to make a comparison with other students, several statistics about their evaluation are given. 47% of the students failed (obtained a result below 5 in any of the assignments). 27% of the students passed the assignments obtaining a “C” grade (in the range of 5 to 7). 11% of the students received a “B” grade (ranging from 7 to 9), and 15% of them were awarded an “A” grade (above 9). No student obtained an “A+” grade. As can be deduced from the results stated previously, most students pass the assignments, however, only few of them could obtain such a high grade, and Rafael was one of those students who obtained an “A” grade. Table 3. Evaluation of the VIS Teaching Results Adapted assignments for the Visually Impaired Student
Partial Score
Practical Weight
Assignment Score
Lab. equipment and safety
—
—
—
Instrumentation introduction
—
—
—
Basic logic gates
100 %
5%
0.5
NAND, NOR synthesis
100 %
5%
0.5
Combinational I
100 %
5%
0.5
Combinational II
90 %
10 %
0.9
Adder/Subtracter
100 %
15 %
1.5
Combinational MSI I
100 %
10 %
1.0
Combinational MSI II
90 %
10 %
0.9
Counters
90 %
15 %
1.35
Registers
100 %
15 %
1.5
20
Flip-flop Global score (over 10)
6.2.
100 %
10 %
1.0 9.65
Teaching Assistance
A VIS requires much more guidance than a non-‐VIS: for instance, a VIS can plug incorrectly a cable into a socket (not properly plugged, or plugging it in a nearby socket, etc.) It is also very common to guide the finger of a VIS to the first socket of each chip. The professors were advised in advance by Rafael and his tutors about some of these inconveniences. Due to that, a classmate and an assistant professor were assigned to help him. In most of the assignments, Rafael required a constant assistance from the assistant professor. Most times, the help required was that of taking his finger to the first socket of each chip used in the solution. Sometimes he also asked for help when debugging. In this task, most of the mistakes were due to wrong insertions of the cable into the sockets: he did not plug completely the connector into the socket. Rafael required little assistance from the assistant professor only in the first practical session, which was the easier one. Thus, his behavior about asking for help from the professor is similar to the one of his classmates: the only difference was that his requests for help was more continuous.
7.
Conclusions and Enhancements
Three main aspects of this work are to be emphasized in this section. At first, the integration of a VIS with his classmates. At second, the learning process of the student. Finally, the lecturer assistance, which is required. Finally, some enhancements are suggested to improve this work. VISs are able to carry out their work at the same time and in the same location as the other students. The fact that these students are not treated differently than their peer helps minimize any perception of preferential or discriminatory treatment. The opposite was also achieved: most non-‐VISs showed interests in performing their assignments using the same platform that Rafael used. The learning process of a VIS has been designed to be easily affordable. In particular, the experience with Rafael has been highly positive as the student has notably assimilated the knowledge required in this course, mainly due to the high motivation he used to face the practical sessions. On the contrary, the main weakness of this system is that the assistance of an additional lecturer is required. During the first five weeks, one sole lecturer is able to manage the situation. However, since week 6th, regular students require much attention from the lecturer, mainly due to learning problems with OrCAD. Thus, a second lecturer to assist the VIS is needed. In general, to count on two lecturers since the beginning of the course is advisable.
Acknowledgements The authors would like to thank Prof. Dr. Manuel Hernández Calviño for his inestimable support and interest. This work was partly supported by the Xilinx University Program and the Vice Chancellor of European Higher Education Area and Undergraduate Degree Programs.
References W.A. Barry, J.A. (1994) Gardner, and T.V. Raman, Accessibility to Scientific Information by the Blind: Dotsplus and ASTeR could make it easy, in Proceedings of the 1994 CSUN Conference on 21
Technology and Persons with Disabilities, USA. E. Bel and E. Bradburn (2008), Reframing Teachers' Conceptions of Accessible E-‐Learning Designs, in Proceedings of the IEEE International Conference on Advance Learning Technology. 1023-‐1027. Santander, Spain. Benyon D., Turner P., and Turner S. (2005), Designing for Interactive Systems, Addison Wesley 104; 404-‐417. J. Fricke and H. Baehring (1994), Design of a tactile graphic I/O tablet and its integration into a personal computer system for blind users, Electronic Proceedings of the EASI High Resolution Tactile Graphics Conference. Graham D., Benest I., and Nicholl P. (2007) Interaction Design For Visually Impaired Students: Initial Findings, 8th Annual Conference on the Teaching of Computing. Southampton, UK. G. Gray and S.M. Wilkins (2005), A snapshot of 2003-‐4: blind and partially sighted students in Higher Education in England and Northern Ireland, British Journal of Visual Impairment: 23(1), pp. 4—10. M. Harrison, C. Stockton, and E. Pearson, (2008) Inclusive, Adaptative Design for Students with Severe Learning Disabilities, in Proceedings of the IEEE International Conference on Advance Learning Technology. 1023-‐1027. Santander, Spain. J-‐Y. Huang, M-‐C Tung, M.W. Kuei, and K-‐J. Chang, (2004) A user interface for the visual-‐ impairment, Displays: 25(4), pp. 151-‐157. Freedom Scientific, Inc. JAWS for Windows Headquarters Website http://www.freedomscientific.com/jaws-‐hq.asp . M.J.C. Mommers, (1975) Some factors related to Braille reading by blind children in elementary schools, The Louis Braille British conference on research into reading and listening by the visually handicapped, Cambridge, UK, pp. 26-‐46, 1975 H. Pyy, C. O'Donnell, and F. Monteiro de Carvalho (2007), Virtual Magnifying Glass 3.3, http://magnifier.sourceforge.net, 1999-‐2007. A. Rodríguez-‐Ascaso, et al. (2008) Personalised support for students with disabilities based on psycho-‐educational guidelines, in Proceedings of the IEEE International Conference on Advance Learning Technology. 1021-‐1022. Santander, Spain. S.M. Rogow, (1987) The ways of the hand: a study of hand function among blind and visually impaired multihandicapped children and adolescents, The British Journal of Visual Impairment: 5(2), pp. 59-‐61. S.M. Rogow, (1990) The development of hand function in young visually impaired children, Realities and opportunities: Early Intervention with Visually Handicapped Infants and Children, Proceedings of the International Symposium of Visually Handicapped Infants and Young Children, American Foundations for the Blind. Royal National Institute for the Blind (RNIB) National Centre for Tactile Diagrams (NCTD) \url{http://www.nctd.org.uk C. Stovall and W.E. Sedlacek, (1983) Attitudes of male and female university students towards students with different physical disabilities, Journal of College Student Personnel: 24(4), pp. 325— 330. R. Tubiana, J.M. Thomine, and E. Mackin, (1984) Examination of the hand upper limb, Philadelphia: 22
W.B. Saunders. Philadelphia, USA.
23
Design of an autonomous and cooperative robots laboratory
Guillermo González-‐de-‐Rivera, Ricardo Ribalda, Angel de Castro, Javier Garrido
Dept. Ingeniería Informática. Escuela Politécnica Superior. Universidad Autónoma de Madrid. C/ Francisco Tomás y Valiente 11. 28049 Madrid (Spain). {guillermo.gdrivera, ricardo.ribalda, angel.decastro, javier.garrido}@uam.es
Abstract This paper proposes a new hardware/software platform designed for laboratory practices of autonomous robots. The course is offered in both Computer and Telecommunications Engineering, but is flexible enough to be offered in other technical degrees. The open design of the platform allows the students to focus their work either in software or hardware aspects. The offered hardware platform is enough for allowing practices in which only the software is changed, focusing on algorithm design and software tests, using almost any programming language under multiple OS. On the other hand, students can also focus on the hardware design, developing and implementing new peripherals with sensors or hardware controllers, and forgetting about software integration problems. This is possible thanks to a set of easy rules for rapid software integration provided in the platform. Using this new platform a set of new competences are available.
1. Introduction This paper proposes the laboratory practices of a course in robotics offered in the Computer Engineering degree of the Universidad Autonóma de Madrid (Spain). This is an elective course of the last course of the degree. It tries to complement the previously acquired knowledge with some additional formation in control and electronics, offering the possibility to design and implement a HW-‐SW project. In order to show the acceptance among students in Computer Science, Fig. 1 shows the number of students registered in the proposed course in robotics compared to the average number of students registered in the other possible elective courses. Although only students in the last two years can register in elective courses, the percentage is with respect to the total number of students in the Computer Science degree. The proposed course was about 2% below the rest of courses in the first academic years, but has been in the average or even above the average during the last 5 years. We have to take into account that this improvement is in spite of the strong laboratory content in mechatronics and electronics, which are usually not well accepted among Computer Science students. Although the course includes both theoretical and practical contents, the practical part has more weight. The main element of these practices is a new robotics design platform. This platform is the result of a series of research projects developed since 2005. The robotics course started in 1999-‐ 2000. In that first year, students had to develop their own simple control board for the robot. Given the profile of the students, with not much expertise in electronics design, few groups (formed by couples) obtained a complete and working (although simple) robot. In order to solve this problem, the next year a development control board designed ad-‐hoc, 24
GP_Bot (Glez de Rivera et al, 2002), based on a Motorola 8-‐bits microcontroller was used, each group using their own unit.
Fig. 1: Comparative of % of students in elective courses For the initial specification, it was established that the new system should be a flexible, general purpose and low cost one. It should have enough resources for managing the elements of a basic robot, such as motors, infrared sensors, switches, etc. On the other hand, it should have enough processing capability and memory for managing artificial intelligence algorithms, creating maps of its environment, etc. These last objectives should be studied carefully, because if not the design could be much more complex and expensive. The solution was to combine the flexibility, size and low cost of a microcontroller with the processing capabilities of a PC. The link between both elements is a radio module that enables bidirectional communication between both processors. In this way, the PC is in charge of the complex processing tasks, while the microcontroller, which is on-‐board in the robot, manages the motors and sensors. Anyway, the system allows to use the microcontroller in an autonomous way if no complex processing is necessary. Using this platform all the groups obtained a working robot programming the GP_Bot platform and developing different algorithms. During the next years, the designed robots have evolved and the GP_Bot platform was not enough in all cases. Therefore, in 2005-‐06 the proposed platform, GdRBot (Glez de Rivera et al, 2005a; Glez de Rivera et al, 2005b), started to be used. It is quite more complex and ambitious. The GdRBot platform, shown in Fig. 2, consists on a set of generic robots that can be controlled either remotely or locally by a set of heterogeneous devices. Furthermore, it allows adding new sensors or actuators to the robots in a very simple way. The main contribution of the platform is allowing the student to create complex algorithms which can be run in the robot, using any programming language with almost no limitation, in the same way that would be used for programming a simulator.
25
Fig. 2: GdR-‐Bot Platform
2. Platforms description 2.1 GP_Bot platform Basic description The GP_Bot platform is basically formed by two blocks: the control unit (CPU) and the external interfaces, as shown in Fig. 3. The control unit is the Motorola MC68HC908GP32 8-‐bit microcontroller. Its architecture is based on the M68HC08 family, being optimized for C compilers and control applications. It is completely static and includes design options for low power. It can work in Monitor mode, in which the internal resources can be accessed from a PC, including registers and memory (both Flash and RAM) content, and even allowing step-‐by-‐step execution of the stored program, which is very useful for tests and debugging.
Fig. 3: GP_Bot platform A QFP (quad flat pack) package of 44 pins was chosen, allowing a reduced size board (70 x 65 mm) and the maximum number of I/O for the user. The microcontroller is the core of a board with the following characteristics: 26
•
MC68HC908GP32 microcontroller with a crystal at 9.8304 MHz.
•
RS-‐232 driver (MAX232).
•
Radio communications module using the 433 MHz band.
•
Power supply of 5 V.
•
Input for the Monitor cable connected from the PC.
•
External access to all the I/O pins of the microcontroller.
As a complement, an auxiliary board was designed which is an interface between the GP_Bot board and some transducers, such as motors, infrared sensors and switches. It also has some I/O general purpose pins for the designer. The size of this auxiliary board is the same as the GP_Bot, and the connectors are located in the same position, creating a compact and small set with both boards. Its main characteristics are: •
Interface with up to 4 dc motors or 2 step-‐by-‐step motors.
•
Direct connection with 4 infrared sensors, including their polarization.
•
8 analog inputs, which can also be configured as digital I/O.
•
The motors can be powered with voltages different from the digital voltage.
The driver for the motors is based in two L293D chips, while the infrared driver is designed for the connection of 4 CNY70 or equivalent sensors. Each infrared sensor can be read from a digital or analog pin. This allows the system to distinguish between more than two colors. Laboratories contents During the course, a series of laboratory practices are held ranging from the basics of the platform to complex tasks. As an example, the laboratories contents of the 2001/02 academic year are shown: •
Laboratory 1 o First approximation to some basic sensors: polarization, tests and measurements. o GP_Bot board presentation. Compiler and debugging tools. o Interface with the PC. o Design and implementation of a mobile robot. o Simple problem solution.
•
Laboratory 2 o Radio communication between the robot and a PC.
•
Laboratory 3 o Control algorithms design: application to the control of dc motors.
•
Laboratory 4 o Basics of artificial intelligence: application to the creation of a map of the environment.
Acquired competences •
Analysis and interpretation of datasheets. 27
•
Asynchronous serial communication protocol RS-‐232.
•
Implementation of algorithms in real systems.
•
Low complexity control problems solution using embedded systems.
2.2 GdR_Bot platform Basic description The GdRBot platform consists in a series of generic PC-‐based robots and their basic control. These robots can be either controlled remotely or locally by a heterogeneous set of devices. They also allow the easy integration of new sensors or actuators. The main contribution is that the student can develop high level complex algorithms to be executed in the robot, while the basic control software (direct control of motors and sensors) is already part of the offered platform. These algorithms can be developed in almost any programming language, exactly the same as if a simulator were used. Hardware description: the only requirement of the hardware platform is to be able to run Linux. Multiple hardware platforms could be used. However, the students are provided with a working hardware platform, which is shown in Fig. 4a. Its main control device is a VIA EPIA motherboard, model TC10000 at 1 GHz with 512 Mbytes of RAM. This is enough for almost any algorithm the students can develop in a course. The board includes connections via Ethernet, Wifi, Bluetooth, GSM modem, and any Linux supported device can also be added. The list of available sensors in the platform includes a video camera, ultrasonic and infrared detectors, and diverse switches and buttons. Most of the available sensors are controlled in a distributed architecture using GP_Bot boards connected to the GdRBot using a serial protocol (sensor server, Glez de Rivera et al, 2005c). In this way, the central controller and the sensors controllers can be separated: the central controller just sends requests and receives measurements. As a result, any other sensor can be included with the only condition of being compliant with the serial protocol. Regarding actuators, there are two motored wheels and a free wheel. The motored wheels use a step-‐by-‐step motor controlled by a dedicated processor. The complete robot is mounted on an aluminium structure and powered by a 12 V plumb battery. The robot is quite compact, with a total size of 20x30 cm approximately.
a. Based on EPIA
b. Based on XScale Fig. 4: Two different hardware platforms 28
In the last academic year, 2008/09, a new HW design has been incorporated (see Fig. 4b) with the following characteristics: • Device based on the Intel XScale PXA255 Microprocessor • Sensorial servers: GP_Bot platform • Network interfaces: Wireless, Ethernet, USB port, and Serial ports. • Geared DC (Faulhaber 1624E012S model). Motor driver TLE4207G. • Two infrared sensors (Sharp GPD2D12). • Two ultrasound sensors (SRF04). • 6 V battery. Software description: the VIA EPIA motherboard runs Linux, and a web server is mounted on it, which is in charge of receiving actuation or sensing requests via XML-‐RPC. In order to use the robot, any XML-‐RPC compliant system can be used. The platform provided to the students includes a client and server examples. The client sends requests and supervises the servers through XML-‐RPC calls (Glez de Rivera et al, 2009). The server is always installed in the robots, while the client can either be installed in a robot or any other system. Clients installed on robots are used for self-‐management tasks, such as avoiding collisions, and for cooperative tasks. Laboratories contents The laboratories of the course includes 4 practices. A basic schedule is proposed, which includes most elements but not in much depth. Students can choose to change their schedules to get in further depth in some aspects. The basic schedule is as follows: • Practice 0. Introduction to the GdRBot platform. Using a basic robot, students start to control it using high level languages such as Java or C#. The basics of XML-‐RPC calls are studied. • Practice 1. Adding a new sensor using the GP_Bot board. Students add a new sensor using the GP_Bot board as its direct controller. The basics of microcontroller programming are learnt. • Practice 2. Integration of the sensor in the platform. Once the student has controlled a sensor using the GP_Bot, the sensor subsystem is integrated in the robot developing a CGI accessible via web. The student learns how to program XML-‐RPC functions and how to create CGIs. • Practice 3. Cooperative tasks. A task that demands a cooperative behavior is proposed,
forcing the interaction between robots that use the sensors previously integrated. The objective is to make the student realize about the complexity of cooperative algorithms.
Acquired competences •
Analysis and interpretation of datasheets.
•
Criteria for choosing the option that better solves a specific problem. The previous platform had all the necessary components for the laboratories. In the new platform, the student must choose the most appropriate components.
•
Ability to solve problems that appear in the physical implementation that were not considered in the theoretical design. During the physical implementation can appear problems not considered in the theoretical design, such as signal interference, external 29
noise, impedance coupling, etc. The student must be able to solve them. •
Ability to choose between different communication protocols and to use them. In the new platform, students have more communication options (Ethernet, Wifi, Bluetooth, GSM MODEM, ZigBee, etc), so they must choose the best solution for their problem.
•
Implementation of mid-‐complexity algorithms in real systems. The algorithms are not only simulated, but also implemented in physical embedded systems.
•
Ability to solve mid-‐complexity control problems, based on embedded systems and cooperative systems. The new platform has an architecture that allows to solve problems using cooperative systems.
3. Results Since the new platform is being used, the complexity of the laboratory practices has increased, but also the competences acquired by the students. Table 1 shows the number of students registered in the proposed course and the percentage of students that passed it. In spite of the increase in the laboratories complexity, the number of students has kept on growing and the percentage of success remains in satisfactory levels. As it can be seen, the percentage of success was always above 80%. Table 1: Academic success of the course Robotics.
Academic Year Computer Science Eng.
09/00 00/01 01/02 02/03 03/04 04/05 05/06 06/07 07/08
# Students
29
33
39
34
62
93
64
62
72
% Passed
96,6
88,8
92,3
100
87,1
86
100
80,6
84,7
4. Conclusions Using the proposed GdRBot platform, students can learn the theoretical and practical aspects of complex robot tasks. Almost any programming language and OS can be used during the course. Thanks to the new platform, which is complete but open to new additions, the course can be focused either in software or hardware development, or a mixture of both. Regarding the acquired competences for the European Higher Education Area (EHEA), they have been notably improved in comprehension and application aspects with respect to the previous laboratories model. The academic results after changing the platform have not changed significantly in spite of the important increase in the complexity level of the laboratories.
References G. Glez de Rivera, G., López-‐Buedo, S., González, I., Venegas, C., Garrido, J., Boemo, E. (2002). GP_BOT: Plataforma Hardware para la enseñanza de Robótica en Ingeniería Informática. In Tecnologías Aplicadas a la Enseñanza de la Electrónica (TAEE'02). Las Palmas de Gran Canaria, Spain, pp. 67-‐70. Glez. de Rivera, G., Ribalda,R., Colas, J., Garrido, J. (2005a). A Generic Software Platform for Controlling Collaborative Robotic System using XML-‐RPC, In Proceedings of IEEE/ASME International Conference on Advanced Intelligent Mechatronics (AIM 2005). Monterrey (USA), 30
ISBN: 0-‐7803-‐9047-‐4, pp. 1336-‐1341. Glez. de Rivera, G., Ribalda, R., Koroutchev, K., Colas, J., Garrido, J. (2005b). Hardware Independent Architecture for Autonomous Colaborative Agents, In Proceedings of 2nd International Conference on Informatics in Control, Automation & Robotics (ICINCO-‐2005), Barcelona, Spain, pp. 459-‐462. Glez. de Rivera, G., Ribalda, R., Colás, J., Garrido, J. (2005c). Plataforma genérica para desarrollos basados en agentes móviles. Actas de Ubiquitius Computing & Ambient Intelligence (UCAmI-‐05), Granada, Spain, pp. 363-‐369. Glez. de Rivera, G., Ribalda, R., de Castro, A., Garrido, J.(2009). Performance of an open multi-‐ agent remote sensing architecture based on XML-‐RPC in low-‐profile Embedded Systems. Proc. of 7th International Conference on Practical Applications of Agents and Multi-‐Agent Systems (PAAMS’09), Y. Demazeau, J. Pavón, J.M.Corchado, J. Bajo, Advanced in Intelligen& Soft Computing vol 55,Salamanca, Spain, ISBN: 978-‐3-‐642-‐004867-‐2, pp. 520-‐528.
31
Database design using a web-‐based e-‐learning tool Josep Soler (1), Imma Boada (1), Ferran Prados (1), Jordi Poch (1), Ramon Fabregat (2) (1)
Department of Computer Science and Applied Mathematics. University of Girona Campus Montilivi. Edificio P4. 17071 Girona (josep.soler,imma.boada,ferran.prados,[email protected] (2
) Institute of Informatics and Applications. University of Girona Campus Montilivi. Edificio P4. 17071 Girona [email protected]
Abstract ACME-‐DB is a web-‐based e-‐learning tool for skills training and automatic assessment of main database course topics. This tool is composed of a set of correction modules each one designed for a specific type of problems. Among them, entity-‐relationship diagrams, relational database schemas, normalization, relational algebra and SQL. In this paper we describe how ACME-‐DB has been used in teaching/learning of database design in our university and how it has influenced in the academic results.
1. Introduction All the computing disciplines specified by the ACM/IEEE/AIS curricula provide the general guidelines of a database course (http://www.acm.org/education/curricula-‐recommendations) . The issue of how to meet these guidelines is not addressed and different studies have been carried out to analyze the contents covered in the database courses. The majority of educators (Robert et al., 2000; Springsteel et al., 2000; Robert & Ricardo, 2003) agree that they spent the most time of the course on main topics of database development stages, i.e. database design, relational model and Structured Query Language (SQL). These topics are part of the core of computing disciplines and are extensively covered in leading database textbooks (Elmasri & Navathe, 2007; Connoly & Begg, 2005; Date, 2004; Silberschatz, 2005). Despite not being a general consensus in the database course contents the majority of them have as the main objective to introduce students to main database topics and take them through all stages of database development. But, as important as the course contents is the teaching methodology applied by educators. In general, teachers agree that students have to receive a solid background in concepts, introduced in teaching classrooms, as well as practical development of database skills. In this context, web-‐based teaching and learning resources have become fundamental and a valuable tool to complement and support teaching classrooms (blended learning). However, although current e-‐learning tools are able to cover the majority of database course contents, it is difficult to find a unique environment that supports all of them and also the automatic correction of exercises. To overcome this limitation in 2003 we started to develop the ACME-‐DB environment which is part of the ACME1 platform (Soler et al, 2002). ACME-‐DB is a web-‐based e-‐learning tool for skills training and automatic assessment of main database course topics. Its main feature is the automatic correction of database exercises. ACME-‐DB is composed of a set of correction modules each one designed for a specific type of problems. Among them, entity-‐relationship diagrams, relational database schemas, normalization, relational algebra and SQL. Moreover, it provides 1
The acronym ACME stands for the catalan for “Continuous Assessment and Improvement of Skills”
32
support to different teaching requirements such as continuous assessment, student tracking, etc. ACME-‐DB is used in our university as a complement to traditional classroom database courses in Computer Science degrees since the 2004/2005 course. Since then the number of activities has been increased leading to an improvement on the academic results. The goal of this paper is to describe the experience of applying ACME-‐DB in database design of our university and how it has influenced in the academic results. The paper is structured as follows. In Section 2, related work is presented. In Section 3, we present the ACME-‐DB environment. In Section 4, we describe how ACME-‐DB has been used in teaching/learning of database design and we present the obtained results. Finally, in Section 5, conclusions and future work are presented.
2. Related work In this section we give a quick overview of the database design contents and a description of the teaching methodology applied in our university. Afterwards, we briefly review the different e-‐ learning tools described in the literature to support teaching and learning contents in database design. 2.1. Teaching Database design Database design is one of the main topic of any introductory database course. The creation of a database requires a design process to define types, structures and constraints for the data to be stored in the computer. This process can be summarized in four main steps:
First, the analysis of the requirements of the real world situation that has to be represented.
Second, the definition of the conceptual schema that gives a high level description of the database and the requirements that data must satisfy. The most popular approach for conceptual schema designing is the Entity-‐Relationship (ER) model (Chen, 1976). The ER model considers the world as a set of entities and the relationships between them.
Third, the definition of a logical design which gives a high level schema implementable on a database management system. The relational model (Codd, 1970) is the most common data model used for database management. It represents the database as a collection of relations where each relation resembles a table of values. To create relations with no redundant data, with an efficient data organization and that can be modified in a consistent and correct manner, a normalization process is applied.
Fourth, the definition of a physical design which represents the internal data storage details.
When all these concepts are acquired, students have the knowledge required to implement a relational database schema using any one of the available Database Management System (DBMS). 2.2. Database design in our University The methodology applied in the database courses of our university is the following. There are lecture sessions, where the teacher introduces main theory concepts and laboratory sessions where exercises are assigned to the students to put in practice these concepts. These exercises are related with real cases and take student trough the different stages of the design process. To star, the student creates conceptual models for small problems. Once these concepts are acquired 33
more complex exercises are assigned. The next step is devoted to logical design concepts. The student transforms a conceptual model into a logical model targeted to a relational database implementation. Students learn to map a conceptual model into a logical model that can in turn be readily transformed into a relational database schema. At this point, the central concepts of the relational model (domains, keys, integrity constraints, and so on) are engaged. Finally, the database schema is created. The student defines the tables, with the corresponding attributes, primary and foreign keys, etc. A good strategy to acquire database design skills is to solve exercises similar to real-‐world problems. With this purpose different exercises are assigned to the students. The most critical issue is the time required to correct these exercises. Moreover, if we consider that the solutions are not unique. To establish a trade-‐off between the number of exercises and the time required to correct them, we gave to the students a list of exercises and only some of them were corrected in the class. In addition, two of these exercises were assigned to the students as homework and then they were corrected by the teacher. The main drawback of this strategy was that students only solved the assigned problems. Due to the importance of practice in the context of these courses and considering the requirements of the new European Higher Education Area, we decided to integrate e-‐learning tools in the applied methodology in order to overcome the detected limitations. Fortunately, the functionalities of our e-‐learning platform, ACME, satisfy these requirements. In addition, ACME provides support for the course management, student tracking, etc. For all these, we developed the modules needed to support the automatic correction of ER diagrams, relational database schemas and normalization. In this way, we will be able to support in a same environment all the functionalities required to cover the database design needs. This new environment, denoted ACME-‐DB, is described in Section 3. 2.3. Database design Tools In last years a large number of e-‐learning environments that provide and support different teaching and learning topics of database courses have been proposed. In this section, we describe the most representative. To present them we consider three different groups according to the main topics of the database design process: conceptual and logical design and normalization. ER diagram Correction Tools: As it was previously mentioned, the ER model is the most popular approach for conceptual schema designing. Such a model considers the world as a set of entities and the relationships between them. Therefore, an ER diagram tool has to provide an environment able to support the definition and correction of ER diagrams. The system has to be able to interpret the diagram giving the corresponding feedback to the student. Over the last decade several attempts to develop ER problem solving web environments have been made (Constantino-‐Gonzalez & Suthers, 2000; Suraweera & Mitrovic, 2002; Thomas et al., 2007; Batmaz & Hinde, 2007). The most representative is KERMIT proposed by (Suraweera & Mitrovic, 2002). KERMIT is an intelligent tutoring system that contains a set of problems and ideal solutions to them. The system compares the student solutions to the ideal solution using domain knowledge represented in the form of constraints, which are classified into syntactic and semantic ones. Relational Database Schemas Correction Tools: The relational model represents the database as a collection of relations. To define this model the student has to define a set of tables for a given situation of the real world. Therefore, the tool has to provide an environment able to support the definition of tables, with the corresponding attributes, keys and foreign keys and also, the 34
capability to correct and give feedback about correction. It has to be taken into account that the solution of a relational design problem is not unique. Few tools to support and correct logical database design have been proposed. The most representative is ERM-‐Tutor (Milik et al., 2006), a constraint based tutor that teaches logical database design (i.e. mapping conceptual to logical database schemas). Students solve the problem step by step and receive feedback on their solutions. Normalization Tools: The normalization process is applied during the relational model definition to create relations with no redundant data, with an efficient data organization. To teach the normalization process a set of functional, multivalued and join dependencies are given to the student and he has to obtain the corresponding normalized schema. Normalization tools display a relation with the corresponding dependencies, the student propose a normalized schema entering a set of normalized relations and the system has to correct them. Most of existing tools for database normalization have not been conceived as web-‐based environments but as software applications that automate some step of the normalization process. To best of our knowledge there are few web environments that support database normalization learning (Kung & Tung, 2006; Zhang et al., 2005; Mitrovic, 2002). The most representative is NORMIT proposed by Mitrovic. NORMIT is a web-‐enabled tutor for database normalization where the student selects a problem and goes through a number of steps to analyze the quality of the database following a fixed sequence of actions: determine the candidate keys, the closure of a set of attributes and prime attributes; simplify functional dependencies, etc., with a specific web page for each task. Student solutions are analyzed by the system receiving feedback. This environment is a question-‐ answer based approach since student does not propose a solution, he answers if the displayed solution is correct or not. Despite the advantages provided by the described tools with respect to more classical teaching methodologies, they still present several limitations. We consider that one of the main limitations of these tools is that they are specific applications not integrated in a general e-‐learning platform. Hence, they do not support lecturer tasks, such as continuous assessment, tracking of students work to detect weak points, features to obtain statistics of common errors, number of attempts required to solve a problem, etc. For a lecturer all these features are very important since they provide information of student progress and also which topics need further work. On the other hand, another common limitation of the majority of tools is that they do not support automatic correction and only provide a way to show the results of a given exercise for a predefined database. The student has to compare the obtained result with the correct solution. Such an approach is difficult to apply when more than one solution per exercise is possible. Besides the functionalities of a common e-‐learning platform we consider that an e-‐learning environment has to support automatic correction of problems. The capability to automatically generate and correct different exercises allows giving personalized attention to each student. With this idea we conceived the ACME platform.
3. The ACME-‐DB environment In 1998, we started to develop ACME an e-‐learning platform to improve both teaching and learning at the technical/engineering degree programs of our university (Soler et al., 2002). The platform was conceived to integrate new types of problems with minimal modifications. The ACME-‐DB environment is an extension of the ACME tool designed to support in a unique environment the main topics of a database course. We started to develop ACME-‐DB in 2003 with the development of the relational database schemas module (Prados et al., 2005). Since then, entity-‐relationship diagrams (Prados et al., 2006), normalization (Soler et al., 2006), SQL and 35
relational algebra (Soler et al., 2007) correctors have been developed and integrated in the environment. In the following we only consider entity-‐relationship diagrams, relational database schemas and normalization correctors. All these modules apply the same methodology which is briefly described below.
ACME-‐DB has a repository with the problems entered by the teacher. Each problem consists of a descriptor and the procedures required for its automatic correction. In the case of ER diagrams, relational database schemas and normalization problems, due to its complexity, all the possible solutions are entered. ACME-‐DB provides a text editor to enter the problems.
The student enters in the ACME-‐DB environment and once in the system a list with the exercises that compose their workbook appears. This information is presented in a tabular form as it is illustrated in the example of Fig. 1(a). In this example the workbook contains five topics, labeled in the first column of the displayed table from 1 to 5. For each topic, as it can be seen in the second column of the table, there is a different number of exercises. Each row of the table displays the topic, the number of exercise, if it has been solved or not and the number of send solutions. The exercises of the workbook have been assigned automatically by following the teacher specifications and by using the problems stored in the repository of the system.
The student selects one of the exercises of his workbook and proposes a solution. In Fig. 1(b) an example of a problem descriptor is given. To enter the solution, there is a specific interface which is specifically designed for each type of problem. In Fig. 2 we illustrate the interfaces corresponding to ER diagrams and relational database schemas. The ER interface (Fig. 2(a)) integrates different designing tools to create an ER diagram. The different parts of the interface are: (a) buttons to draw the elements of the ER-‐diagram, when a button is pressed its corresponding glyph graphic is drawn in the working area, a rectangle for entities, a diamond for relationships, with two lines connecting the two entities previously selected; (b) working area; (c) menus for input attributes; (d) zoom and (e) correction button. The interface for relational database schemas problems is represented in Fig. 2(b). To design a relational database schema the student defines the tables and the different attributes that compose them. These tables are represented in the screen. Each time the student press the Add button of this interface the information of the items appears in the corresponding table. The normalization interface is similar to the one of Fig. 2 (b).
36
(a)
(b)
Fig. 1: (a) Workbook interface and (b) Problem descriptor
The solution entered by the student is send to the corresponding corrector and the correction process is done automatically. In our case, the correction strategy is based on a matching process that compares the student solution with each one stored in the repository. If no matching is found, the most similar solution is selected and is used to return feedback. These feedback messages are designed according to the type of problem, and in case of errors return some help to obtain the correct solution. For instance, “More entities are required”, “There are incorrect relation-‐ships”, etc.
For each student the system records all the entered solutions. This information is used to grade the exercises. The grading process uses a function specifically designed for each type of problem where different parameters are taken into account. For instance, in the ER diagrams we consider the number of correct/incorrect entities/relationships/attributes, the number of attempts before a correct solution is obtained, etc. The marks of all the problems are used for continuous assessment.
(a)
(b)
Fig. 2: Interfaces for entering solutions (a) ER diagrams and (b) relational database schemas 37
4. Results The different modules were designed, implemented and then tested on an experimental database course 2004/05. We evaluate the modules independently, obtaining very promising results. In this section, we describe how the ACME-‐DB environment has been used in database design and the obtained results. Due to the bad results achieved with the previous methodology (see Section 2.2) we decided to modify it introducing the ACME-‐DB platform. The idea was to introduce this tool to improve database design skills acquisition. We applied a new teaching/learning methodology where ACME-‐ DB has a main role. The goal was exploit all the capabilities of the platform to assign, solve and automatically correct the activities assigned to the students. The system creates a different workbook for each student containing exercises of the main topics: ER-‐diagrams, relational database schemas and normalization. For each topic we define exercises of different complexity according to the number of entities or relations. The easier exercises range from 5 to 10 entities/relations while the more difficult from 15 to 20. These exercises are used for continuous assessment contributing in a 50% on the final mark and the resting 50% is obtained from an exam done at the end of each topic. The continuous assessment mark is obtained automatically taking into account student work: the number and type of errors, the number of solutions before the correct one is obtained, etc. The capability to automatically obtain this mark reduces the time required to correct exercises allowing teacher to spent time in other tasks. To control students work the teacher tracks their solution and according to detected errors he can propose additional tasks in order to improve the learning process. In Table 1, we collect the results obtained using the platform in the last four years. For each one of the three topics (ER-‐diagrams, relational database schemas and normalization), we give the number of students, the number of assigned problems, the % of students that have read the problems, have sent solutions, have sent correct solutions and also the % of students that have solved the problems at the first, the second, the third and with more than three attempts. Note that more than 80% of students read the exercises and more than 70% solve them correctly. The number of students that obtain the correct solution at the first or second attempt is between 63% and 80%, and the rest requires three or more attempts. Table 1. Information obtained from the ACME-‐DB tool with respect to its use.
To evaluate the impact on the academic results we compare the results obtained before the application of ACME-‐DB with the results obtained in these last four years. This data is collected in Table 2. For each course we give the number of students and also their final marks graded from A to D, where A corresponds to the best mark and D the worst. The NP column represents the students that have not assisted to the course. Finally, in the two last columns we give the % students that have passed and not the course, respectively. Note that the results obtained when 38
using ACME-‐DB (2005/06 to 2008/09) are better than when no using the platform. Moreover, if we analyze the number of students that have passed the course there is a considerable increment compared with the results obtained when no using the platform. We consider that these better results are due to the fact that the student feels supported all the time. He knows that when he has a solution he can obtain the automatic correction at any moment. Table 2. Academic results no using and using (grey background rows) the ACME-‐DB environment
Finally, in Table 3 we evaluate the relationship between the number of students that have solved the ACME-‐DB exercises and the number of student that have passed the course. We group students in three different rows according to the exercises that have solved correctly. In the first row students that have solved less than 50%, in the second between 50% and 75% and in the last row more than 75%. For each group of students and for each course, we give the % of students and the % of students from this group that has passed the course. Note that when students solve correctly less than 50% of exercises the possibility of passing the course is minimal. On the contrary when they solve more than 75% of exercises the number of students that pass is greater than 80%. Table 3. Relationship between the number of students that have solved the ACME-‐DB exercises and the number of students that have passed the course
Despite the advantages provided by the ACME-‐DB environment, it has to be taken into account that this new methodology requires an extra work in order to prepare exercises for the students. The main advantage is that these exercises are stored in the repository of the system and can be used in different courses. In general, teachers consider that the application of the ACME-‐DB has improved their teaching methodology and this is reflected in the final marks.
5. Conclusions We have presented ACME-‐DB a web based environment to support teaching and learning of database design. We have described the main modules that integrate this environment and how it has been applied in a database course of our university. Data collected during four years of application showed how academic results have been improved. Our future work will be centered on a more exhaustive analysis of collected data. We also plan to develop the module that supports the automatic correction of conceptual object modeling using UML class diagrams. 39
References Batmaz, F. and Hinde, C.J. (2007). A web-‐based Semi-‐automatic Assessment of Conceptual Database Diagrams, In Proceedings of the 6th Web-‐Based Education WBE 07, Chamonix, France, 427-‐432. Chen, P. (1976). The entity-‐Relationship model. Towards a Unified View of Data, ACM Transactions on Database Systems, 1, 9-‐36. Codd, E.F. (1970). A relational Model of Data for Large Shared Data Banks, Communications of the ACM, 13, 377-‐387. Connoly, T. and Begg, C. (2005). Database Systems: A Practical Approach to Design, Implementation and Management, 4th Edition Addisson Wesley. Constantino-‐Gonzalez, M. and Suthers, D.D. (2000). A coached collaborative learning environment for entity relationship modelling. In Proceedings of 5th International Conference Intelligent Tutoring System ITS 2000. Montreal, Canada, 324-‐333. Date C.J. (2004). An Introduction to Database Systems, 8th Edition Addisson Wesley. Elmasri, R. and Navathe, B. (2007). Fundamentals of Database Systems, 5th Edition Addison Wesley. Kung, H. and Tung, H. (2006). A Web-‐based Tool to enhance Teaching/Learning Database Normalization, In Proceedings of 2006 Southern Association for Information System Conference, Jacksonville, USA. 251-‐258. Milik, N., Marshall, M. and Mitrovic, A. (2006). Teaching Logical Database Design in ERM-‐Tutor. In Proceedings of 8th International Conference Intelligent Tutoring System ITS 2006, Jhongli, Taiwan. LNCS 4053, 707-‐709. Mitrovic, A. (2002). Normit: a web-‐enabled tutor for database normalization, In Proceedings of International Conference on Computers in Education ICCE, Auckland, New Zeland, 1276-‐1280. Prados, F., Boada, I., Soler, J. and Poch, J. (2005). An Automatic Correction Tool for relational Database Schemas, In Proceedings of International Conference on Information Technology based higher Education and Training ITHET05, Santo Domingo, Dominican Republic, S3C 9-‐ 14. Prados, F., Boada, I., Soler, J. and Poch, J. (2006). A web based-‐tool for Entity-‐Relationship Modeling, In Proceedings of International Conference on Computational Science and its Applications ICCSA 2006, Glasgow, UK, LNCS 3980, 364-‐372. Robbert, M.A., Wang, M., Guimaraes, M. and Myers, M.E. (2000). The Database Course: What must be taught, ACM SIGCSE Bulletin, 32, 403-‐404. Robbert, M.A. and Ricardo, C.M. (2003). Trends in the evolution of the Database Curriculum, ACM SIGCSE Bulletin, 35, 139-‐143. Silberschatz, A., Korth, H. and Sudarshan, S. (2005). Database System Concepts, 5th Edition McGraw Hill. Springsteel, F., Robbert, M.A. and Ricardo, C.M. (2000). The next Decade of the Database Course: Three Decades speak to the next, ACM SIGCSE Bulleti, 32, 41-‐45. Soler, J., Poch, J., Barrabes, E., Juher, D. and Ripoll, J. (2002). A tool for the continuous assessment and improvement of the student’s skills in a mathematics course, In Proceedings of International Symposium of Technology of Information and Communication in Education for 40
engineering and industry TICE 2002, Lyon, France, 105-‐110. Soler, J., Boada, I., Prados, F. and Poch, J. (2006). A web-‐based Problem-‐Solving Environment for database Normalization, In Proceedings of 8th International Symposium on Computers in Education SIIE 2006, León, Spain. Soler, J., Boada, I., Prados, F. and Poch, J. (2007). An automatic correction tool for relational Algebra Queries. In Proceedings of International Conference on Computational Science and its Applications ICCSA 2007, Kuala Lumpur, Malaysia, LNCS 4706, 861-‐872. Suraweera, P. and Mitrovic, A. (2002). KERMIT: A Constraint-‐Based Tutor for Database Modeling, In Proceedings of International Conference Intelligent Tutoring System ITS 2002, Biarritz, France, LNCS 2363, 377-‐387. Thomas, P., Waugh, K. and Smith, N. (2007). Tools for supporting the teaching and learning of data modeling, In Proceedings of World Conference on Educational Multimedia, Hypermedia and Telecommunications EDMEDIA 2007. Vancouver, Canada, 4014-‐4023. Zhang, L., Kaschek, R. and Kinshuk (2005). Developing a Knowledge Management Support Systems for Teaching Database Normalization. In Proceedings of 5th International Conference on Advanced Learning Technologies ICALT 2005, Kaohsiung, Taiwan, 344-‐348.
41
The cost of learning and teaching Java in the Bologna process Camino Fernández (1), David Díez (2), Jorge Torres (3), Telmo Zarraonandia (2) (1)
Universidad de León. Escuela de Ingenierías Industrial e Informática. Campus de Vegazana, 28071-‐León [email protected] (2)
Universidad Carlos III de Madrid. Departamento de Informática. Escuela Politécnica Superior. Avda. de la Universidad, 30 – 28911 Leganés (Madrid) {david.diez,telmoagustin.zarraonandia}@uc3m.es (3)
Tecnológico de Monterrey. Campus Querétaro. Epigmenio González No 500, Fracc. San Pablo, Querétaro, Qro CP 76130 (México) [email protected]
Abstract The European Higher Education Area (EHEA) involved in the Bologna process tries to change both the academic organization and the way teaching is implemented at University. Regarding the way of teaching, an instructional strategy focused on teaching will be replaced by methodologies focused on students learning. This paper shows the pilot case study of an introductory programming course in Java of the degree in Computer Engineering performed to estimate the resources needed to start up with these new methodoligies. During a complete semester, students followed a continuous assessment process that involved an extra effort for both students and teachers. The results show that students were benefitted by the experience, but university is not really prepared to support the whole process with its actual parameters. Keywords: EHEA, Bologna Process, introductory programming course, Java lenguage, case study.
1. Introduction The overarching aim of the Bologna Process is to create the European Higher Educational Area (EHEA) by making academic degree and quality assurance standards more comparable and compatible throughout Europe (Bologna, 1999). The EHEA claims not only a homogenous academy system that facilitates mobility of students, graduates and higher education staff around Europe, but also education plans and methodologies focused on students learning. In this context, new instructional strategies and redesigned courses are needed. With the purpose of making straightforward this process of change, different innovation projects have been performed. In particular, Universidad Carlos III de Madrid performed a pilot case study in the first year of the degree in Computer Engineering. This pilot case study aimed at simulating the EHEA context in order to identify further needs and to assess their cost. Our experience in an introductory programming course of such a pilot has disclosed both positive and negative issues. On one hand, the results of the course have been improved if compared to the previous ones, and students have considered the course structure very positive. On the other hand, dedication of teacher, coordination activities, as well as instructional resources should be actually increased to achieve the goals established. The rest of the paper is organized as follows. The description of the pilot case study, its goals and context, are described in section 2. Section 3 briefly explains the most relevant outcomes of our pilot case study. Finally, conclusions and a set of recommendations and ideas for further discussion are compiled in the last section. 42
2. Description of the pilot case The pilot project was conceived by the university three years before the first new grade was introduced. The objective of these pilot courses was both estimating the resources needed to start up with the new grades, and also knowing the students response to the new learning and teaching methodologies. Having presented the problem that motivated our work, the following subsections explain the learning context in which our introductory programming course was deployed. 2.1. Instructional Strategy Teachers involved in the pilot case were trained on how Bologna should be implemented. According to experts consulted for this project, three main concerns should be considered:
The main point was that everything that implies an effort for students should be measured. Thus, active learning activities as asking questions, proposing new themes or answering teacher’s proposals would be considered as a small part of the final mark.
Students’ feedback should be continuous. Futhermore, the result of that assessment should be returned to the students as soon as possible. Feedback helps to correct the errors and to have a better appreciation of the deficiencies that should be overcome.
Monitoring activities might observe the evolution of the subject. The final objective is that teachers identify knowledge gaps among students in order to have a better understanding of potential corrective activities.
2.2. Course Methodology The course is taught in the first semester of the year of the degree in Computer Engineering. The course lasts for fifteen (15) weeks with a total of five (5) teaching hours per weeks – including theory and laboratory work -‐. The course is coordinated by one teacher and it is taught by eight teachers, with an extra help of another two teachers for the first year. The first year 141 students, and the second year 122, split into three groups, took the course. A common approach in programming education is first to teach the basics of a programming language and then guide students towards effective strategies for the whole programming process (Robins et. al, 2003). Usually, introductory programming courses are focused on teaching about a particular programming language (Lahtinen et. al, 2005). In our case, the course focuses on the object oriented programming paradigm and includes a set of basic programming concepts, such as data types, control sequences and character chains, as well as basic knowledge on algorithms. Java is used as the reference programming language. The course includes lectures and laboratory work. Laboratory work is made up of several programming exercises. Such exercises should be resolved in groups of two students. Programming exercises are handed in at regular intervals throughout the course. The final grade is obtained by combining the results obtained in theoretical examinations (sixty percent of the final grade) with those from practical laboratory sessions (forty percent of the final grade). 2.3. Assessment Process The course included seven (7) multiple-‐choice exams and eleven (11) practical exercises distributed in the fifteen (15) weeks of the course. Both types of assessments were included in the continuous evaluation. At the end of the semester, students took their final written exam and also implemented a small application in java (1000-‐2000 code lines). As we said before, activ class participation contributed to the final mark also, but this contribution is considered only for those 43
students that pass the tests and the laboratory work.
3. Results According to the pilot project’s objetives, two main issues should be analyzed: (i) academic results; and (ii) human resources needs. With the purpose of identifying pros and cons, we have considered data to the same introductory programming course for seven years. The last two ones correspond to the pilot project. Regarding the academic results, as shown in Fig. 1, a different situation can be observed before and after the pilot project. Before the pilot project a high rate of students usually took the first exam but only a low rate passed that first exam. The explanation for those results is that students were facing their first exams at university and they were used to taking all the exams, like they had done in previous studies, although they were not properly prepared for them. The situation in the second chance, September exam, was quite different: The rate of students taking the exam is quite lower, but the rate of students that pass it is much higher. Our experience shows that in this second chance, only the students that are really prepared take the exam. After the pilot project everything changes. In the first exam we have slightly more students, but from those students a much higher rate pass the exam, in fact, in graph a) the trend has swapped. In the second exam there is also a higher rate of students taking the exam, but the number of students that pass it has decreased significantly. This change in the trends shows that continuous evaluation can be an important tool to adapt the course to the students needs and obtain better results.
Fig. 1: Academic results Regarding human resources needs, Fig. 2 shows the total amount of hours dedicated to this pilot project by every one of the ten teachers involved in it. The total amount of time traditionally assigned to teachers was doubled by the estimated time assigned for the pilot project. However, 44
real data collected shows that the final amount of time was even increased in more than a thirty per cent. The most important increase was related to coordinating (teacher 3) and monitoring activities (teachers 7 and 8). Mandatory tutorships were included in order to know students´ needs and opinions; thus, two more teachers were joined to help with these activities.
Fig. 2: Human resources
4. Conclusions The main lesson to be learned from this pilot case is that pilot cases are themselves crucial in situations like this one, where a whole process changes, and this change involves a variety of stakeholders. The main features of that change as, for instance, moving the attention to student’s effort or emphasizing the assessment process, were clear from the beginning. Nevertheless, the big amount of small but essential practical details which can make a new initiative fail or success are not shown until a real case starts up. Although reduced groups were one of the main issues in the Bologna process, one of the direct applications of the pilot cases is reducing the groups to a maximum of 20 students. This apparent advantage implies extra work for the course coordinator. These kind of introductory courses usually have between 150 and 200 students and many teachers have to be coordinated for offering a homogeneous course. The key to face the Bologna process implementation successfully is to provide teachers with the tools needed to simplify the process. Not only tools to facilitate coordination among teachers are needed. Effective tools to improve the whole assessment process are even more important, for instance, communication tools that automate the informative feedback of every assignenment (Diez et. al, 2008) because this task has proved to be the most time consuming one.
References Bologna Declaration (1999). Joint declaration of the European Ministers of Education. Retrieved Febrery 20, 2009 from http://www.ond.vlaanderen.be/hogeronderwijs/bologna/documents/MDC/BOLOGNA_DECLARATION1.pdf
Diez, D., Diaz, P., Aedo, I. and Fernandez, C. (2008). DEI-‐CHECK. Automating the assessment process to improve the informative feedback. In Proceedings of the 38th Annual Frontiers in Education Conference, Saratoga Spring, USA.
45
Lahtinen, E., Mutka, K.A. and Järvine, K.M. (2005). A Study of the Difficulties of Novice Programmers. In Proceedings of the 10th Annual Conference on Innovation and Technology in Computer Science Education, Monte de Caparica, Portugal. Robins, A., Rountree, J. and Rountree, N. (2003). Learning and Teaching Programming: A Review and Discussion. Journal of Computer Science Education, volume 13(2), pp. 137-‐172.
46
A High School Educational Platform based on Virtual Worlds Mariano Rico (1), David Camacho (1), Xavier Alaman(1), Estrella Pulido (1) (1)
Escuela Politécnica de la Universidad Autónoma de Madrid Ciudad Universitaria de Cantoblanco Calle Francisco Tomás y Valiente, 11 28049 – Madrid, Spain {Mariano.Rico, David.Camacho, Xavier.Alaman, Estrella.Pulido}@uam.es
Abstract Virtual Worlds, through their three-‐dimensional or two-‐dimensional graphical environments, have become a very popular kind of software application that has been used in different fields, from games to simulation or education. They allow individuals to interact with others through their avatars and with objects in the environment. Virtual Worlds provide new education opportunities where collaboration and cooperation among users can be easily achieved. This paper presents an innovative educational approach that can be applied to different educational areas, and levels, from basic to higher. Initially it has been oriented to teach computer science to high-‐school students. The paper analyses how the current virtual world platforms should be modified so that they can be used in education. It also describes the main issues and problems that need to be solved in order to develop an operative educational platform for undergraduate students. Finally, a usability evaluation study of several existing technologies (3D virtual world platforms, development programming environments, etc.) performed by several (high school) students is presented.
1. Introduction Although Virtual Worlds (VW) have been used in different domains such as Economy (Sinrod, 2007), Social or E-‐Commerce (Talbot, 2008), the most popular are related to massively-‐ multiplayer online games2. However, VWs can be used as a new powerful instrument for instruction and education allowing social interactions, which can be a basis for collaborative education. The attractive 3D graphical environments provided by these VW can be used to improve interaction and a sense of realism. Different initiatives aimed at applying VW to learning, or educational, processes exist. For example, the work of (Baker, Wentz, & Woods, 2009) shows how psychology instructors can use Second Life as a meeting space with students, and to create labs, buildings, and objects that can be used to learn psychology contents and skills. (Cunha, Raposo, & Fuks, 2008) use Second Life as an environment for collaborative learning and generating of new educational contents. The creation of an environment and a location for collaborative learning in Second Life was the focus of the work of (De Lucia, Francese, Passero, & Tortora, 2008), in which objects have been modeled and programmed to support the synchronous role-‐based collaborative activities required by the jigsaw learning technique in a 3D virtual meeting setting. In the specific context of teaching technical subjects, Second Life has been used with medical and health librarians and educators (Boulos, Hetherington, & Wheeler, 2007), in order to explore the pedagogical potentials of Second Life as well as some issues and challenges related to the use of virtual worlds. The recent work of (Bourke, 2009) analyzes how multiple remote participants can engage in 3D geometry within a virtual environment. 2
http://en.wikipedia.org/wiki/List_of_MMOGs
47
This paper presents an innovative educational platform, named VLEAF (Virtual LEArning platForm), which has been designed to stimulate interest and learning ability of students through the use of technologies that are familiar and particularly attractive to them. It also facilitates the implementation of collaborative (students sharing knowledge on a particular topic) and cooperative (students perform a task or solve all together a common problem) teaching techniques. By using the VLEAF platform, the learning model goes from one in which students have an almost passive role (apart from a minimal interaction) and learns on their own, to one where students play the leading role in the learning environment and work with other students and teachers in the creation of knowledge that can be shared with others. Our approach uses a particular Virtual World, named OpenSim that has been recently developed by IBM and is compatible with Second Life, as the base element to implement the new educational platform. The initial goal of this work is to develop a teaching community where students can acquire basic skills related to computer programming. For this reason, an introductory programming course oriented to high school students is designed to analyze how VWs could be adapted and what other elements, such as web portals, documentation or multimedia support are needed to provide the necessary access to both educators and students.
Fig 1. VLEAF platform
2. An educational platform based on VW When teenagers want to use this kind of domains there are some resources that need to be provided. The VLEAF platform is composed of the following elements: -‐
Web portal that allows: fast access to any documentation; student management (two 48
different roles: administrator and educators); access to multimedia information -‐
Data Bases that are used to store: technical and user guides; educational documentation (courses guides, multimedia, etc..); teacher and student profiles; student educational material; Data mining information (logs, conversations, student and educator interaction in the VW, …)
-‐
Other software programs: data mining and statistical software
-‐
VW grid, that provides: physical spaces where the lecture or laboratory can take place; physical spaces to store the educational objects created by teachers and students.
Fig. 1 shows a graphical representation of the platform. The Web portal3 provides educators or students access to technical and educational material. The VLEAF platform has been built on a grid over OpenSim, based on our previous experience in Second Life (SL), this new grid has been designed to allow restricted access educational spaces for high school institutions. Our first campus4, still available at SL and deployed past 2008, is located at the European University, an SL island where there are currently about 20 universities. OpenSim provides an open fully compatible with SL simulation 3D environment that solves the previously mentioned problems. We can define as much space as we need for educators (it is free, so there is no cost associated to the educational task), the information can be stored in locally owned servers, so that it can be analyzed later by educators, and the control over all this world is in the educator hands.
3. A basic programming course in VLEAF Although some important elements of our platform are still under construction (especially those related to the automatic restricted access for high school students), both virtual worlds (at SL and OpenSim) are enough deployed to allow controlled experiments. This section provides a simple case study to test some of the functionalities of our platform. We have designed a programming course to show how a scripting language (the Linden Scripting Language) works. This course has been tested with several high school students, to find out what kind of facilities need to be provided for future experiences with other educational institutions, and students. Initially a basic programming course has been designed to evaluate the potential interest of students in learning these basics by using the VW technologies (Heaton, 2008). This course provides the basics about working in the OpenSim VW and about algorithm programming, and it has been designed as follows: 1. (1 h) Introduction to VW: installation, avatar creation, and brief introduction to VW 2. (1 h) Basics of building: basic introduction to building and creating prims and linking them to form objects. Rotation, position, and other more advanced attributes of prims are studied 3. (1h) Introduction to LSL: syntax and basics of the Linden Scripting Language. Compiling and debugging a script in the VW; how to create scripts and perform basic operations; script structure 4. (1h) Data and variables in LSL: basic data types and variables in LSL; programming script examples 5. (1h) Control structures: how to control scripts through variable values, conditional sentences, 3 4
http://www.ii.uam.es/~dcamacho/vleaf http://www.ii.uam.es/esp/sl/ index.html
49
and the three different loop types available in Second Life 6. (1h) Strings in LSL: comparing and parsing strings in LSL; programming script examples 7. (1h) Objects and Events: sending instant messages; introduction to event-‐based programming 8. (1h) Advanced Data types & Algorithms; lists in LSL to hold a collection of items; searching and sorting algorithms For each session several usability parameters have been measured, to analyze how attractive and useful this environment is for learning basic programming concepts. The questionnaire details and the experimental setup and results can be found in section 4. 3.1. High-‐School educational processes in VLEaF When the potential users of an educational environment similar to the one described in the previous section are teenagers, special care must be taken in order to avoid harassment or any other kind of possible attacks to this kind of users. For this reason, although VLEAF can use our current campus at SecondLife, access to the VLEAF educational platform will only be allowed through our grid at OpenSim. In this grid we can control at any moment the avatars connected and the actions that they could be doing (these actions are saved through the vamp server as data logs). The platform needs to provide the following roles to different users: -‐
Administrator. S/he can control any avatar within the platform (it can only be applied over the grid deployed under OpenSim VW)
-‐
Educators. They will have the control over their student team . They will control (through the logs stored related to their students) and can prevent a connection for a particular student or students. They will manage the educational materials (in traditional formats and in the format of educational virtual objects) available through the web portal and the Virtual World.
-‐
Students. They can access different educational documents through the web portal, and solve exercises proposed by educators through the Virtual World.
Currently the control over high school students are made by a peer-‐to-‐peer process where the administrator of the system provides a set of predefined avatars (including names and passwords) to the responsible educators. Student and Educator interactions in the VW are saved by using the Vamp Server which allows its analysis.
4. Usability evaluation of VLEaF platform This section describes the usability and user satisfaction parameters measured with their related tests, and the practical conclusions achieved. In this evaluation two selected sets of four educators and (high school) students were used to test the platform and to obtain the usability (based on user’s skills), the user satisfaction, and the potential of this platform applied over educational processes. To obtain the user’s skills, we calculate the sum of the numerical values freely auto-‐assigned by each user depending on his/her level of competence on the client side issues described in the questionnaire. The usability of VLEAF was measured by means of a popular standard test called “Practical Heuristics for Usability Evaluation” (Perlman, 1997). This test includes 13 questions ranging from 1 (bad) to 5 (good), which provides a useful measure of the user’s perceived usability. The results of this test are shown in left part of Fig. 2. This figure shows that three types of users can be identified: those with basic skills (range 0-‐20), medium (20-‐40), and advanced 50
(greater than 40). The first two groups are associated to students, divided in basic and advanced. The third group is associated to teachers, with higher experience and skills. The figure shows high usability values for the whole range of participants, although as one might expect, the most skilled users assign slightly lower usability values. A possible explanation is that skilled users are more demanding, and these results in slightly lower evaluations, but even these advanced users provide high usability values. The standard deviation in each range is low for basic students (0.2) and teachers (0.3), denoting a uniform knowledge, but increases for advanced students (0.5). This denotes slightly variations in usability for this range of users, but within reasonable values.
Fig. 2. Left: Usability of VLeaF for different user skills. Right: User’s satisfaction on the user interface as a function of the user skills. The user’s satisfaction concerning the VLEAF user interface, was measured by means of a slightly modified version of the standard test “User Interface Satisfaction” (Chin, Diehl, & Norman, 1988). The standard version includes 27 questions, but it was reduced to 25 due to overlaps with the usability test described previously. Valid responses to these questions were positive integers ranging from 0 (not satisfied at all) to 7 (completely satisfied). It must be noted the different scale value compared to usability range. The results, showing the dependency between the user’s satisfaction and his/her skills are shown in the right part of Fig. 2. The average value for user satisfaction was 5.5, and It is worth noting that the user satisfaction depends on the user skills in the same way that usability, that is, higher-‐skilled users assign a slightly lower value to satisfaction. Three ranges can be identified as it was for usability (the first two for basic and advanced students, and the third one for teachers), and the behavior of the standard deviation for each range follows the same that usability, that is, small deviations for basic students (0.4) and teachers (0.3), and bigger (0.7) deviations for advanced students. From experimental results we can conclude that VLEAF provides good average values for usability and user satisfaction concerning the user interface for a wide range of user competencies, what confirms that VLEAF is a highly usable platform for users in a wide range of skills, from non initiated ones (students) to advanced ones (teachers).
5. Conclusions According to the report on the implementation and use of ICT in schools for primary and secondary education (year 2005-‐2006) under the Plan Avanza5, the 71% of Spanish teachers never 5
http://www.oei.es/tic/TICCD.pdf
51
use a computer to support explanations at their lectures, and 82.2% do not use ICT for presentations or simulations, although the 94.6% stated to have access to computers at their school, and many of them admit that ICTs have a great educational potential. These data demonstrate that new resources are not generally used in primary and secondary education. The reason could be related to the need of an operative infrastructure and tools, services and contents to facilitate their lectures. The use of the proposed platform would solve this problem as it allows educational resources developed by individual students or teachers to be used by others. From our initial empirical evaluation, we have observed that the Virtual World provides a very attractive domain where students discover that learning can be an interesting experience. Although there exist a huge amount of information in Internet related to Virtual Worlds (such as Second Life or OpenSim) or to programming, there is no specific documentation oriented to high-‐school students. Finally, the proposed programming course (based on a simple introduction to C-‐style scripting languages such as LSL) is definitively more interesting than the traditional ones.
Acknowledgments This work has been funded by the Spanish Ministry of Science and Innovation under the projects VLEAF (TIN2008-‐02729-‐E/TIN) and HADA (TIN2007-‐64718). We would like to thank the VLEAF developer team, and students from I.E.S. Antonio de Nebrija for their cooperation in this work.
References Baker, S. C., Wentz, R. K., & Woods, M. M. (2009). Using Virtual Worlds in Education: Second Life as an Educational Tool. Teaching of Psychology, 36(1), 59-‐-‐64. Boulos, M. N. K., Hetherington, L., & Wheeler, S. (2007). Second Life: an overview of the potential of 3-‐D virtual worlds in medical and health education. Health Information and Libraries Journal, 24(4), 233-‐245. Bourke, P. (2009). Evaluating Second Life for the collaborative exploration of 3D fractals. Computer & Graphics -‐UK, 33(1), 113-‐117. Cunha, M., Raposo, A., & Fuks, H. (2008). Educational technology for collaborative virtual environments. Proceedings of the 12nd International Conference on Computer Supported Cooperative Work in Design. Chin, J. P., Diehl, V. A., & Norman, K. L. (1988). Development of an Instrument Measuring User Satisfaction of the Human-‐Computer Interface. Proceedings of ACM CHI'88 Conference on Human Factors in Computing Systems. De Lucia, A., Francese, R., Passero, I., & Tortora, G. (2008). Supporting jigsaw-‐based collaborative learning in Second Life. Proceedings of the 8th IEEE International Conference on Advanced Learning Technologies. Perlman, G. (1997). Practical usability evaluation. Proceedings of the CHI '97: CHI '97 extended abstracts on Human factors in computing systems. Sinrod, E. J. (2007). Virtual world litigation for real. Available on line at http://news.cnet.com/Virtual-‐world-‐litigation-‐for-‐real/2010-‐1047_3-‐6190583.html. Talbot, D. (2008). The fleecing of the avatars. Technology Review -‐Manchester NH-‐, 111(1), 58.
52
Comparing a fully online course to a blended one: the case of compilers Salvador Sánchez Alonso (1), Daniel Rodriguez García (1), Robert Clarisó Viladrosa (2) (1)
Information Engineering research unit, Universidad de Alcala Ctra. de Barcelona, Km. 33.6, 28817 Alcalá de Henares, Spain {salvador.sanchez,daniel.rodriguezg}@uah.es (2)
IT, Multimedia and Telecommunications Department, Universitat Oberta de Catalunya Rambla del Poblenou 156, 08018 Barcelona, Spain [email protected]
Abstract The compilers course is part of the degree in Computer Science that the Open University of Catalonia (UOC) –an online university located in Barcelona– currently offers in fully online mode. In the University of Alcala (UAH), located in Madrid, the same course is given in a traditional, face-‐to-‐face format. Based on the experience of the teachers of these courses during the 2008 academic year, this paper reports on a study carried out to determine whether students at UOC, who take only online courses perform (and consequently learn) as much as students taking identical course in a traditional university (UAH). Preliminary results comparing their marks in the first assessment of the course indicate that the amount of learning is similar in both settings.
1. Introduction The Open University of Catalonia (UOC) is a virtual university aimed at complementing the Catalan university system “by making university studies available to citizens who cannot enroll for a face-‐ to-‐face university degree” (Borges, 1998). As teachers in a traditional (so to speak) university, the University of Alcala, we were curious about how different our UOC students would perform compared to our UAH students. After reading on a similar experience by Anstine & Skidmore (2005), we were interested in establishing whether our UOC students, taking a fully online course, were learning as much as our regular students at UAH, even if the latter had unlimited access to teachers, as they could arrange an appointment anytime to meet with a teacher. Our personal perception was that UOC students, more used to work autonomously, would perform better as the assessment task implied an important process of previous documentation that traditional students are not completely familiar with. So, we hypothesized that, contrary to what most people could expect, our UOC students would perform better and consequently would learn more, or at least as much as, those students attending to regular face-‐to-‐face classes. This paper is structured as follows. Section 2 explains the irrespective settings of each of the universities participating in the study, namely UOC and UAH, as well as the motivation for this research. Section 3 details the design of the research and how the study was conducted, showing the most interesting results. Finally, some conclusions and outlook for more comprehensive studies are provided in section 4.
2. Background 2.1. The Open University of Catalonia The Open University of Catalonia (UOC) is a virtual university with more than 54.000 students all around the world (UOC, 2008). Currently, UOC offers undergraduate degrees in Catalan and Spanish and graduate degrees in English, Catalan and Spanish. UOC has offered university degrees 53
in Computer Science since 1997 and currently more than 6.000 students are enrolled in Computer Science courses. Teaching at the UOC is performed through a virtual campus (Borges, 1998), an online platform which aggregates many services oriented towards students and academics, such as: virtual classrooms where they can access course self-‐study materials, submit assignments and communicate with their peers and the course instructors; virtual laboratories for exercising practical skills (Prieto, 2008); and a virtual library that provides access to recommended bibliography, databases and journals. Academics and students communicate asynchronously using public forums or personal mailboxes. Three academic profiles participate in the UOC learning methodology: the counselor, the subject tutor and the lecturer. Counselors provide orientation throughout the degree, guiding the selection of courses and providing information regarding professional openings, etc. Subject tutors answer questions about a specific course, design the assignments used for the assessment of the course and grade the students. Courses with many students are split into several virtual classrooms, each with a different tutor. Finally, lecturers act as coordinators of the team of tutors for a given course and participate in the course design. While lecturers are full-‐time academics at UOC, subject tutors are professional or academics with full time commitment at another institution or company, and which are selected according to their expertise in a given area. As part of its degree in Computer Science, the UOC offers two 6-‐month courses in compiler design and construction, which are compulsory to achieve the Spanish 5-‐year degree in Computer Science (Ingeniería en Informática). These subjects have many prerequisite courses (programming, data structure, automata theory and computer architecture) and therefore they are among the last courses taken by computer science students, typically in the last year of their degree. Table 1 describes the contents of these courses. The course design has not yet been adapted to the European Credit Transfer System (ECTS), but the workload of each course is estimated at 6 ECTS credits. Table 1. Compiler courses in the UOC Computer Science curriculum. Compilers 1 •
•
• •
Introduction to compilers: history, construction process, compiler architecture. . . Front-‐end: lexical, syntactical and semantic analysis, symbol tables, error recovery Back-‐end: code generation and optimization Construction of a compiler front-‐end using JLex and CUP
Compilers 2 • • •
•
Construction of interpreters Mark-‐up languages (XML) Advanced code generation: procedure calls (pass-‐by-‐value vs pass-‐by-‐reference), object-‐oriented programming languages, . . . Construction of abstract stack machine interpreters and use of XML technologies (DTDs, XSLT, Java APIs for XML)
From the point of view of the students, the workload and difficulty of compiler courses is considered “above average” within the Computer Science curriculum. Some points typically raised to argue for this difficulty are: the use of many concepts and techniques from several prerequisite subjects, highly theoretical contents (e.g. parsing theory), long programming assignments and the introduction of new software tools and languages (constructors of lexical and syntactical analyzers), among others. 2.2. The University of Alcala
54
On the other hand, the University of Alcala (UAH) is a public university located in Alcala de Henares, a Unesco world heritage town located 35 km from Madrid, the capital of Spain. The city, founded in the early 16th century, was awarded the World Heritage status in 1988 because it was the world's first planned university city. The UAH offers 3 different degrees in computer science, the most advanced of which has a duration of 4 years –equivalent to 240 ECTS– and allows the student to obtain the Spanish degree in Computer Science (Ingeniería en Informática). As part of its syllabus, this degree includes a compiler course as a mandatory subject whose main topics are detailed in table 2. Table 2. Compiler course in the UAH Computer Science curriculum. Compilers • • • •
Introduction to compilers: history, construction process, compiler architecture. . . Front-‐end: lexical, syntactical and semantic analysis, symbol tables, error recovery Back-‐end: code generation and optimization Construction of a compiler front-‐end using JLex and CUP
The course follows a blended learning methodology, where face-‐to-‐face lectures are combined to virtual learning and interaction through a Moodle parallel course. Lectures, which are approximately 50% of the total time of the course, address the theoretical foundations of the course, and are taught in a traditional classroom. The rest of the time is dedicated to problem solving cases and assignments. During the practical part of the course, lecturers provide some initial guidance on the tools that students must use as well as a few practical examples on simple applications during 3 to 4 face-‐to-‐face sessions. During these sessions, students raise questions about tools use, installation, technical problems in general and the like. Once they master this part, students face three individual assignments during the rest of the course. During their assignment elaboration, students have access to a virtual learning environment –– specifically set up to enhance both student to student and student to lecturer communication. Students use the virtual learning environment to raise questions on the application of theory to their assignments, technical problems, documentation and other communication activities both with their peers and with lecturers. 2.3. Motivation Two professors from UAH’s Compilers course also work as subject tutors in UOC’s Compilers 1 course. This fact provided the opportunity to compare two learning methodologies, fully online learning versus blended learning, in the context of a Compilers course. To this end, we studied the success rate of students in the assessment activities of both courses. An issue which lends credibility to the results is the fact that students in both universities were evaluated using exactly the same assessment activities, and that the grading criteria were also equal (given that all assignments where graded by the same set of professors).
3. Design of the research The comparison was performed during the first semester of the academic year 2008-‐2009. In the UOC course “Compilers 1”, there were three virtual classrooms, two in the Catalan language with 53 and 57 students respectively, and another in Spanish with 27 students, but only the class in Spanish was used for this preliminary study. In the UAH course, there was only a virtual classroom 55
for the 53 students, even though the students were split into two different groups for the lectures part only for their convenience in terms of space and teaching shifts. There are important differences among the profiles of students at the UOC and the UAH. The UOC is oriented towards life-‐long learning and students which cannot attend a face-‐to-‐face university due to personal or work commitments. Therefore, the students from UOC tend to be older on average (UOC, 2008), have work experience and study part-‐time while working full-‐time and/or caring for their families. It is also common that many students from UOC either have a degree on another area, or started a degree which they interrupted for some reason. On the other hand, students at the UAH tend to be younger and studying their first degree on a full-‐time basis, possibly (but not very often) simultaneously with a part-‐time job. This student profile also has a greater urgency to complete their degree quickly in order to enter the full-‐time job market. These differences in student profiles are significant in the study of the success rate. For example, as time is a very important resource for UOC’s students, students only invest time in solving an assignment if consider they have a reasonable chance of success (rather than failing, they simply will not submit the assignment). Meanwhile, UAH’s students have incentives to work on assignments even if they know their solution will not be optimal (getting feedback from course instructors and avoid “wasting a semester”). 3.1. Teaching and assessment mechanisms In both universities, UOC and UAH, the assessment of the compilers course is carried out in a similar manner. UOC offers theirs students two alternative paths to pass the compilers course: 1. Three continuous assessment activities, followed by a validation test. 2. A final exam at the end of the course. Both paths assess the theoretical concepts of the course and the practical issues as it is shown in table 3 –see how practical aspects play a very important role in these activities and therefore have an important weight in the final mark–. According to experience, continuous assessment improves the assimilation and understanding of concepts, especially in a distance learning environment. Therefore, continuous assessment path is the one recommended by OUC course instructors and the one selected by almost all students. Table 3. Organization of the assessment activities at UOC
• • •
Structure of a compiler (front-‐end/back-‐end, phases, symbol table, . . . ) Compilation vs interpretation Compiler construction (bootstrapping, cross-‐compilers, . . . ) Lexical analysis phase
Practice (70%)
• •
Definition of regular expressions Construction of lexical analyzers using JLex and Java
Theory (30%)
• • •
Syntactic analysis phase Bottom-‐up (LR, LALR) and top-‐down (LL) parsing Syntax error recovery
Practice (70%)
• •
Integration of JLex and CUP Construction of a syntactic analyzer (parser) using CUP and
• Theory (30%) Activity 1
Activity 2
56
Java
• •
Semantic analysis phase (attributed grammars, type checking, . . . ) Code generation phase (intermediate code, . . . ) Code optimization phase (goals, algorithms, . . . )
•
Construction of semantic analyzers using CUP and Java
• Activity 3
Theory (30%)
Practice (70%)
The validation test consists of a set of questions that focus on specific aspects of covered by the continuous assessment activities performed throughout the course. This test has two goals: to certify the identity of the student (i.e. the student has solved the assessment activities herself) and to validate the learning process (i.e. the student has understood the concepts and techniques used in the assessment activities). The final grade is computed as the average grade of all continuous assessment assignments, taking into account that in order to pass the student has to pass all continuous assessment assignments and the validation test. Regarding UAH, the assessment is divided into 2 separate parts: 1. A final exam at the end of the course for assessing theoretical concepts and knowledge. 2. Three assessment activities, followed by a personal interview for validation purposes. These assessments address the practical part of the course only. The final grade is computed here as the average grade of the final exam (60% weight in the final mark) and all continuous assessment assignments (40% weight in the final mark). As in the UOC course, the student must pass all continuous assignments to pass this part of the course, but no student assignment is considered valid if the face-‐to-‐face validation is failed, because this test has the same goals previously described for the UOC: to certify that the student has solved the assessment activities herself and to validate the learning process. Table 4 shows the organization of the three assessment activities at UAH. Table 4. Organization of the assessment activities at UAH Activity 1
• •
Definition of regular expressions Construction of lexical analyzers using JLex and Java
Activity 2
• •
Integration of JLex and CUP Construction of a syntactic analyzer (parser) using CUP and Java
Activity 3
•
Construction of semantic analyzers using CUP and Java
3.2. How the assignments were set up and assessed In this paper, we will analyze the results achieved in the first continuous assessment activity in the semester (from the UOC perspective) and the first assignment (from the UAH perspective) as they have exactly the same tutors/lecturers, the same problem statements and a similar period of time to submit their solutions. Assignments consisted on a set of exercises –both theoretical and practical in the case of the UOC and only practical in the case of UAH– that students must solve on their own. Once the problem statements were published, students had a fixed time (which is usually two to three weeks) to 57
submit their solutions. Each assignment typically requires 4-‐5 hours to be completed, in addition to the time devoted to revising the materials (course materials, recommended bibliography and collections of solved problems). To have two comparable groups of students’ results, only the practical part of the UOC assessment activity was used for the study, so the theory part (30%, see table 3) was removed from it. Thus, the UAH and the UOC assignment activities were exactly the same, which allowed using the same criteria to correct both the students’ results of the UOC and the UAH groups. In particular, the assessments were corrected according to a set of criteria classified into 3 groups: essential (E), positive (+) and negative (-‐). We considered essential those requirements that all the student programs must accomplish as a precondition to pass the assessment, while positive and negative criteria were lists of issues that could have an influence on the final mark. More detail on the criteria followed by the courses’ tutors is given in table 5. Table 5. Correction criteria Type of criteria
Description
Comments
E
The archive.lex must be processed by JLex without errors
E
The resulting Java file must compile without errors
Some minor errors were not considered, e.g. using a class name for the scanner other than the one requested
E
The scanner created by JLex cannot end unexpectedly (e.g. due to a not handled exception or the like)
+
The specification file is legible and include comments
+
Lexical patterns are simplified through Usually linked to the previous criteria the use of macros
+
Java code is well structured
The specification file has a method for each functionality instead of having the java code repeated several times
-‐
The specification file does not include the directive %class to change the default scanner class name
One mark was cut out of 10
-‐
The specification file includes too many One mark was cut out of 10 states, most of them unnecessary
-‐
Bad Java code in the specification file
-‐
The student makes use of inefficient or 0.5 mark was cut out of 10 inadequate data structures
0.5 mark was cut out of 10
During all the period of assessment, and up to the deadline for submission, the course instructors were available to answer questions regarding the materials or the comprehension of the 58
assessment wording. In the case of UOC, this help was of course available through the virtual environment, whereas in the UAH the lecturers allocated 2 hours per week to face-‐to-‐face help sessions in the lab, in parallel to the help they provided through the virtual environment. 3.3. Analysis of the results Our initial thought was that students in blended learning would achieve better results than students in an exclusively on-‐line environment, as they have more direct access to lecturers both through the online environment and in the face-‐to-‐face sessions. However this was discarded by just comparing basic descriptive statistics as shown in table 6. Also, and even though the marks do generally follow a normal distribution, this is also confirmed as both standardized skewness and kurtosis are inside the range of ±2. Table 6. Descriptive Statistics Count Average Variance Standard deviation Minimum Maximum Range Standard skewness Standard kurtosis
UAH 53 6.24717 3.57831 1.89164 3.0 9.5 6.5 -‐0.48213 1.29985
UOC 27 6.95185 6.03413 2.45645 1.4 10.0 8.6 1.48045 0.837939
This is also corroborated by the box-‐and-‐whisker plot of Figure 1. As it can be observed, although there is more variance for the on-‐line learning groups, the mean of the marks is higher.
Figure 1. Box-‐and-‐whisker plots for marks To check whether the difference between the means was statistically significant, we run a t-‐test with the following null hypothesis: H0: There is no difference between the means (i.e. the means are the same) Therefore, the alternative hypothesis, Ha, is that there is a difference between the means. Selecting a=0.05, the f-‐test for the equality of variances shows that there is no statistical difference between the variances of both groups and a t-‐test assuming equal variances could be applied (see table 7). 59
Table 7. F-‐Test Two-‐sample for variances Mean Variance Observations df F
UAH 6.24717 3.578309 53 52 0.593012
UOC 6.951852 6.034131 27 26
P(F<=f) one-‐tail F Critical one-‐ tail
0.054473 0.584925
As it can be seen in table 8, the t statistic is lower than the t critical (.23727< 2.30601), and also the p value is greater than a (.0.079 > 0.05). According to this, we can accept the null hypothesis that there is no statistical difference between the means. Table 8. t-‐Test: Two-‐sample assuming equal variances Mean Variance Observations Pooled Variance Hypothesized Mean Difference df t Stat P(T<=t) one-‐tail t Critical one-‐tail P(T<=t) two-‐tail t Critical two-‐tail
UAH 6.24717 3.578309 53 4.396916
UOC 6.951852 6.034131 27
0 78 -‐1.42133 0.079604 1.664625 0.159208 1.990847
Based on the marks obtained in our experiment, we can conclude that knowledge acquired in blended or exclusively online learning is similar. 3.4. Threats to validity We faced 3 different kinds of threats to validity: those concerning the construct validity, those concerning the internal validity and those concerning the external validity of our experiment: •
Construct validity is the degree to which the variables used in the study accurately measure the concepts they purport to measure. In our case, marks were the only way to measure the student´s acquired knowledge.
•
Internal validity is the degree to which conclusions can be drawn about the causal effect of the independent variable on the dependent variables. Potential threats include selection effects, non-‐random subject loss, instrumentation effect, and maturation effect. Although the students are different, it is noting that we only considered students handing in their assignments. Another possible threat is that both groups did not have the same time to work on the assignment (2 weeks for the UOC students vs. 3 weeks in the case of the UAH students). 60
•
External validity is the degree to which the results of the research can be generalised to the population under study and other research settings. Although students in the online course are more mature than in the blended group, their initial knowledge was similar. The only possible difference is that the teaching materials were not identical in both cases.
4. Conclusions and future work The research reported on the comparison of two courses on compiler basics, one fully online given at the Open University of Catalonia (UOC) and another blended one given at the University of Alcala (UAH). The study reported herein was restricted to the first assignment activity of the course as the other 2 were not finished by the UAH course by the deadline. Even though some factors change and the conditions and context cannot be demonstrated to be identical, most conditions were: the assessment to carry out, the teachers who acted as tutors and the evaluation criteria. We first carefully studied possible threats to the study validity, considering all different aspects and concluding that those threats did not have a central influence on the results of our experiment. The tests run on the marks of both groups of students allowed us to conclude that the amount of knowledge acquired in blended learning (UAH) and in exclusively online learning (UOC) is similar. Further work should progress on a more comprehensive study, covering all the stages of the compilers course, namely activities 1 to 3 and not only the activity 1. Also, studying new factors such as the lecturers influence (e.g. do students in other groups perform differently?), time given for assignment resolution, students’ age, etc. would be helpful for getting more comprehensive conclusions. Replications over several years are also a target to address external validity.
Acknowledgements The authors would like to thank Francesc Bagés and Alex Pajuelo for their collaboration in Compilers 1 at the UOC and discussions about the design of Compiler courses.
References Anstine, J., & Skidmore, M. (2005). A small sample study of traditional and online courses with sample selection adjustment. Journal of Economic Education, 36(2), 107-‐127. Borges, F. (1998). UOC and its 'Campus Virtual': A Model for Online University Education, In Proceedings of the 2nd North American Web Developers Conference (NAWEB 98), New Brunswick, NJ, USA. Open University of Catalonia (2008). Annual report 2007-‐2008. URL: http://www.uoc.edu/portal/_resources/EN/documents/memories/0708/memo_eng.pdf Prieto, J. (2008). Ontology-‐based characterization and specification of virtual laboratories in Computer Science degrees. PhD thesis, Universitat Oberta de Catalunya.
61
Learning Engineering by Modeling a Guitar Effects Pedal with FPGAs Joaquín Olivares, José M. Palomares, José M. Soto, Juan C. Gámez Department of Computer Architecture. University of Córdoba. Campus Rabanales. 14071. Spain {olivares,jmpalomares,jmsoto,el1gagrj}@uco.es
Abstract Several Supervised Academic Activities have been proposed in the subject “Digital Electronic Systems” th carried out in the 4 year of Engineering Degree in Automatics and Electronics. The purpose of these works is to implement digital systems in FPGA technology. With these supervised works, the students will be able to prove their knowledgement of the subject. Furthermore, the realization of these works will permit to develop cross-‐activities with others subjects. A project-‐based learning methodology is applied, focusing in this paper in a particular work from one student that consisted in implementing a guitar effects pedal. This activity has been awarded as the Most Innovative Activity of 2007 for this degree by the University of Córdoba.
1. Background Different learning patterns are developed by the students even if they use the same methodology, learning, tools and contextual factors. These differences are owing to personal and contextual factors (Vermunt 2005). Several works present the benefits obtained when individual learning was applied (Liu et al. 2008). These benefits increased when student’ emotions were considered (Lekkas et al. 2008). Because of its particular feature, these differences in learning process are very important in our degree. The subject has around twenty students enrolled from several universities B.S. in Engineering Degrees of three years as Electronic, Electrical, Mechanical or Computer Science. This is the reason whereby students are not completely informed in initial concepts. Therefore, it is necessary to establish a special work timing for everyone The Digital Electronic Systems subject is structured in three thematic blocks (Olivares 2007). The first block is a review of programmable logic devices, DS, and design of DS, and takes about 20% of the total. The second block is dedicated to train the students in advanced hardware programming, using FPGA devices and VHDL language, takes about 60% and is the most important thematic block of the subject. Finally, the last one is dedicated to show the microcomputer as a complex digital system, taking the remaining 20% (Olivares et al. 2008). The students have two different ways of passing the subject: a final and common exam or an individual project. Such project must have an adequate complexity in order to guarantee that students have learnt all the contents proposed in the subject. Furthermore, the students must carry out the project spending the determined hours assigned in the subject guide. The old methodology consisted on a more rigid approach. The 40% of the assessment depended on a series of obligatory practical works. The remaining 60% depended on the final examination. Moreover, several optional works could be considered in the final assessment whenever students pass the subject. Practical works and exams are needed to succeed in passing the subject. However, whenever students pass the subject; it is possible to consider several optional works to improve the final assessment. Due to this methodology all students developed the same practical works. In this way, one can find some negative aspects, which infringe the above mentioned 62
guiding principles (Mathematical, 1993). Equity is not ensured, because all students have unlike knowledge and this might produce different reactions given the situation: practical works too complex for some students or too easy for others. Although the main aim of the proposed activity is to know the concepts of the subject, it is also interesting that the projects contribute to learn or to introduce other subjects, promoting horizontal cross activities (in the same academic course) and vertical cross activities (between current and next academic years). Finally, the students must acquire the ability to design and solve industrial problems. In the last two years, a new methodology based on individual projects was proposed to the students. Project-‐based-‐learning was suggested as a promising pedagogical approach for teaching technological problem-‐solving (Mioduser and Betzer, 2007). The professor suggests each student to develop a particular project in which personal interests were included. Furthermore, the students would be able to suggest themselves their own project provided that it is relatively complex and understable and that it is approved by their professor. This methodology presents a notable improvement in assessment such as it is shown in Section Results In our suggestion, each student has a project that matches his personal interests. Furthermore, the students themselves can suggest their own project, provided that it is complex and comprehensive enough, and that it is approved by their professor. This methodology presents a notable improvement in assessment as is shown in Section Results. The Tuning competences (Tuning 2007) that have been considered as the most important ones for the professional development in this degree are listed below. The aim is to develop these skills among all subjects of the degree:
Capacity for analysis and synthesis.
Basic knowledge of the field of study.
Capacity for applying knowledge in practice.
Capacity for generating new ideas (creativity).
Capacity to learn.
Critical and self-‐critical abilities.
Knowledge of a second language.
With this experimental methodology, different projects will be assigned to different students according to their features. These projects should agree some requirements, in order to ensure the guiding principles: 1) the project is individual, 2) it involves the majority of methods and tools considered within the subject, and 3) it is complete and relatively complicated. These requirements are indispensable for a good assessment, as other experiences reveal (Sklyarov and Skliarova, 2005). In addition we also give our students the opportunity to choose to be examined by means of the old methodology or by the new proposal. All of them voted for the new methodology. All skills are developed with the proposed methodology, with the exception of the “capacity for generating new ideas”, that can be suppressed in basic projects proposed by the professor. A typical assessment criterion in Spain is the range of values between 0 to 10 points; the students need to reach a degree of 5 or higher in order to pass the subject. 63
When the professor suggests the list of projects, he informs the students of the highest evaluation possible attainable with each one. Simple projects with a highest value of 5 are possible, though in this case, a project previously limited to 5 is a project that covers minimum concepts and skills required to pass the subject. In this way, a project limited to 10 must cover advanced topics and to guarantee that the students learn completely the subject. When a determined student proposes a project, the professor studies the proposition and sets the maximum value that the student can obtain with it. The final evaluation obtained for a student is based on the percentage shown in Fig. 1. This percentage is applied to the maximum limited value for the project.
Fig. 1: How to evaluate a project In this contribution, a distinguished project is described in order to present the motivation to select the projects’ contents, how the bases are related with other subjects, and, which competences are developed.
2. Discussion. A project-‐based learning example The design of a guitar multi effects pedal and its implementation in an FPGA device was proposed in the first semester of 2007. This specific project was proposed for one student who enjoys playing the guitar, and he was very interested in it. The project was accepted because it was complex enough and covered the main concepts of the subject. Furthermore, advanced concepts were also introduced. The highest value possible which a student could obtain was 10 points over 10. All competences listed in the previous section were considered. The proposal included the implementation of the following guitar effects: Echo, Flanger, Phasing, Chorus, Clipping, Wah, Phaser, and Distortion (Hunter, 2004). Once the FPGA was programmed with the audio processor designed by the student, speakers and a music source, as an iPod or an electric guitar, were connected to the system to prove that the system worked correctly. The interface with the development board was the buttons and switches to select the effect and its strength, and the 7-‐segments led to see basic information about the processing. To solve this problem a previous mathematical model of each effect was solved on Matlab simulator. In this project an analog to digital converter (ADC), and digital to analog converter (DAC) were used on a controller board. Also memory "first input, first output" (FIFO) buffers were used. Real time processing concepts were introduced with this project. The proposed system is shown in Fig. 2.
64
AK4551
Audio Codec Interface
Read/Write
Signal adder
Distortion
SDRAM Controller
SDRAM
FPGA
Input Buttons
Switches 7-Segments
Fig. 2: Design of the proposed system To develop the design, the student used previous knowledge acquired in other subjects during the same semester. The subjects of the following semester or year were also introduced. Related subjects are shown in bold in Fig. 3. 65
4th Year
First Semester
Last Semester
Electric Machines
Industrial Electronics
Optimization
Control Engineering I
Digital Electronic Systems
Modeling Dynamic Systems
Mechanics Systems
Human-Machine Interface
English
Computer Architecture
Scientific Programming
Applied Electrics
Intelligent Buildings
5th Year
Electropneumatic
Control Engineering II
Programming Robots
Perception Systems
Projects
Industrial Power Electronics
Integrated Production Systems
Safety at Automatic
Real Time Systems
Process Control
Engineering Materials
Advanced Power Electronics
Microelectronics
Computer Networks
Digital Signal Processing
Fig. 3: Organization of the cross knowledge Then, a description of the introduced subjects and the knowledge related for each one is summarized: This academic year:
English: Documentation reading. We remind our students that final project presentation hd to be presented into English Language. In that case, the English professor was the responsible person for evaluating this part.
Scientific Programming: Simulation was carried out by using MatLab and Simulink.
Control Engineering I: Concepts about filter and sampling signals are introduced.
Computer Architecture: The use of memory and FIFO buffers is introduced.
Next academic year:
Control Engineering II: Advanced filters.
Projects: How to write a dossier.
Real Time Systems: The proposed effects are processed and shown while playing music. Initial concepts on real time processing are required.
Digital Signal Processing: Using ADC and DAC. Digital signals.
The instrumental used to develop this project, shown in Fig. 4, was:
A XESS XST-‐3 board, provided with audio codec, ADC, DAC, SDRAM memory, I/O ports and a Spartan-‐3 "XST-‐3S1000" FPGA from Xess (Xess 2005). 66
An electric guitar; that could be substituted by another music source such as an iPod, microphone, etc.
Speaker.
Fig. 4: The guitar effects pedal implemented in an FPGA
3. Other projects developed All projects were implemented on FPGA devices and had a common component based on the use of input/output peripherals, memory and computer architecture concepts. To implement these projects, the students used FPGA devices such as "Spartan 3 Board" from Digilent Inc. The most common work about peripherals used the VGA, because of the complexity to configure the synchronization signals. Moreover, other devices such as the PS/2 mouse and keyboard were used. In most cases, the matter was about games, because of the attractiveness for the students (Carmona et al. 2008), (Tam et al. 2008). Moreover, this kind of projects provides authentic tasks, i.e., tasks which are similar to that performed in "real life". This is a key principle of a good assessment (Waters and McCracken, 1997), (Baker et al. 2005). A good example of this was the implementation of the typical game called ``Simon'', with a visual version. A random color sequence is showed on VGA, the player tries to reproduce this sequence to pass the game level. To accomplish this game, it is required the hardware VGA control, random generator based on internal oscillator, and, external interaction with keyboard or switches. In other project, a lap counter visualized on VGA was implemented and adapted for a slot cars racing game called “Scalextric”. In this case, electronics and electrical concepts were used in order 67
to adapt a basic Scalextric track introducing two photocell sensors. Besides, a small electronic board is designed to connect the sensors to the programmable digital system on FPGA. Learning about asynchronous signals was reached with this kind of projects. In the same way a typical 9-‐puzzle was designed. Keyboard data input, random generator and VGA controller was used in this project. The typical game called Ricochet was designed by using a previous open source version (Goga and Andrei, 2005). In this case, to review and understand a previous design was the first part of learning; later, the student added a new module which consisted on a shooting button. In the design of this new option, interaction with other modules must be updated by the student. Finally, the game was controlled with keyboard and board' buttons, besides a clock divisor was used to control the speed of different game components. A game picture is presented in Fig. 5. Fig. 5: The Ricochet
4. Results A notable improvement in assessment compared to previous years can be observed. In Fig. 6, the students' assessment is shown with the results of the last three years compared to the previous four academic ones. The Old Methodology corresponds to 2002-‐2005 academic period, whereas the New Methodology based on projects corresponds to 2006, 2007 and 2008 academic years. In Spain, the range of values in which a student is evaluated goes from 0 to 10 points, and the student passes the subject when obtaining 5 points or above. An equivalence with the english assessment system could be stated as: (A+) Pass with honors, (A) Pass 9-‐10, (B) Pass 7-‐8, (C) Pass 5-‐6.
68
Fig. 6: Assessment evolution The 2002-‐05 values represent the arithmetic mean of the assessments of these four academic years. The 2006 was the experimental year, that is, the year in which we started the new methodology. In that year we could observe an improvement compared to the average of the previous four years. Similarly, we obtained better results in 2007 and 2008, due to a more precise selection of the amount of time assigned to fullfil the projects. This meant an improvement in the results, as stated in Fig. 5, where 'Fail' percentage fell from almost a 40% of students who failed the subject to a figure below 25% (23%, 8%, and 25%, respectively, in 2006, 2007, and 2008). Moreover, this behavior is also shown for students with C grade, for which a reduction from 42% to 30% was obtained in 2007 and even more for 2008 with no student obtaining a C grade. It is worth mentioning that 2006 has to be taken as an exception, because, for C grade, there was a rising leap to 54% of the students. This happened because the students were able to finish their projects, but just to the minimum required level due to lack of time for further enhancements. For A and B grades, new methodology courses show a significant growing. Finally, no A+ grade was granted (from 2002 to 2006) and in 2007 and 2008 (with the new methodology) aroung 10% of the students obtained such a honored grade. 4.1. Advantages and drawbacks The first advantage is the motivation that these practical works raise a great interest in the students, because they have to work in FPGA and their projects are games. Because of the projects are personal practical works, it is possible to evaluate features such as difficulty, ability, dedication, etc. Due to this, the subject can be adapted in a high grade to students' particular features. Furthermore, this methodology reports continuously on student progress. From the students' point of view, they have the opportunity to evaluate and reflect on their own understanding (Waters and McCracken, 1997). To expose the projects in a foreign language improves the student capacity of expression, contributing to develop the team in an international work competence. 69
The main drawback comes up because it is necessary an important teacher support for each student. In this current academic year, this disadvantage has been mitigated with a scholarship to assist to the students. At the beginning of projects, some students can feel an uncertainty about their own ability to solve the project, but this uncertainty disappears with the course evolution.
5. Conclusions The experience was successfully for students. The assessment presents an important improvement since the failed in previous years was around 40% and by applying the new methodology the failure decreases to a mean of 25%. Moreover, the number of students with graded 7 or more rose to a mean of 53%. Competences listed on discussion section are all developed and evaluated. Moreover the student's capacity to design and to develop industrial electronic systems, based on reconfigurable programmable devices, is guaranteed. This experience corroborates how a methodology based on projects is more appropriate for determined subjects with a high practical component than traditional methodologies based exclusively on examinations. Although reduced groups of students are really necessary due to the high teaching support which is required by each project. With this methodology, two goals are achieved; to guarantee that students are able to perform industrial FPGA designs, and to begin cross activities with other subjects. Obviously, the learning of the essential concepts of the subject is granted. Tuning competences were developed using the proposed educational methodology. An improvement in the assessment and in the learning is achieved, students are more motivated and are more active in the learning process. With the “guitar effects pedal” project, the students passed the subject with honors and a final evaluation of 10. This project was awarded in December 2007 with the Most Innovative Activity of the Year for this degree at the University of Córdoba.
Acknowledgements This work was partly supported by the Xilinx University Program and the Vice Chancellor of European Higher Education Area and Undergraduate Degree Programs.
References A. Baker, E. Navarro, A. van der Hoek. (2005). An Experimental Card Game for Teaching Software Engineering. Journal of Systems of Software, 75. C. Carmona, D. Bueno, M.A. Jiménez (2008). Adapting an Educational Game for Spanish Ortography to Make it Adaptative and Accessible. Eighth IEEE International Conference on Advanced Learning Technologies. D. Hunter. (2004). Guitar Effects Pedals – The Practical Handbook. Backbeat Books. London. Tuning Project. (2007). Tuning General Brochure. Z. Lekkas, N. Tsianos, P. Germanakos, C. Mourlas, G. Samaras. (2008). The Role of Emotions in the Design of Personalized Educational Systems. Eighth IEEE International Conference on Advanced Learning Technologies. 70
T.-‐C. Liu, Y.-‐C. Lin, Kinshuk, M. Chang. (2008). Individual Differences in Learning with Simulation Tool: A Pilot Study. Eighth IEEE International Conference on Advanced Learning Technologies, doi: 10.1109/ICALT.2008.302. D. Mioduser, N. Betzer. (2007). The contribution of Project-‐based-‐learning to high-‐achievers’ acquisition of technological knowledge and skills. International Journal of Technology and Design Education. vol. 18. n. 1. pp. 59 – 77. J. Olivares. (2007). Guía Docente de Sistemas Electrónicos Digitales. Córdoba. Escuela Politécnica Superior. http://www.uco.es/organiza/centros/eps/doc/programas/570006.pdf. Accessed 10 May 2008. J. Olivares, J. Gómez, J.M. Palomares, M.A. Montijano. (2008). Biprocessor SoC in an FPGA for Teaching Purposes. Eighth IEEE International Conference on Advanced Learning Technologies. V. Sklyarov, I. Skliarova. (2005). Teaching Reconfigurable Systems: Methoods, Tools, Tutorials, and Projects. IEEE Transactions on Education, 48(2). M. Spector, R. Hartley, R. Koper, Kinshuk, A. Elsayed. (2008). A Competency Approach: Implications for E-‐Learning and E-‐Assessment. Eighth IEEE International Conference on Advanced Learning Technologies. V. Tam, Z.X. Liao, A.C.M. Kwan, C.H. Leung, I.K. Yeung. (2008). Developing an Interactive Game Platform to Promote Learning and Teamwork on Mobile Devices: An Experience Report. Eighth IEEE International Conference on Advanced Learning Technologies. J.D. Vermunt. (2005). Relations Between Student Learning Patterns and Personal and Contextual Factors and Academic Performance. Higher Education. 49. pp 205 – 234. R. Waters, M. McCracken. (1997). Assessment and Evaluation in Problem-‐Based Learning. The 27th Frontiers in Education Conference. Xess. (2005). Xstend Board V3.0 Manual. http://www.xess.com/manuals/xst-‐manual-‐v3_0.pdf. Accessed 25 July 2008.
71
Using IMS-‐LD Standard to Support Learning in Teaching ICTs in Industrial Design Engineering Rocio Garcia-‐Robles(1), Fernando Díaz-‐Del-‐Río (2) (1)
Escuela Técnica Superior de Ingenieria Informática, Universidad de Sevilla Avda. Reina Mercedes s/n, Sevilla 41012 [email protected] (2)
Escuela Técnica Superior de Ingenieria Informática, Universidad de Sevilla Avda. Reina Mercedes s/n, Sevilla 41012 [email protected]
Abstract IMS-‐Learning Design specification was designed to support the authoring of reusable and pedagogically neutral learning scenarios and contents. Although it is especially suitable for eLearning, its use in traditional face-‐to-‐face Higher Education scenarios may be interesting, mainly because it supports formal description of teaching practices, and that type of information oftenly remains as tacit knowledge in HE learning scenarios. This paper presents the outcomes of using such standard to innovate teaching practices in “Introduction to Informatics”, a subject taught in the Industrial Design Engineering School at University of Seville. Its pedagogical design is based on the IMS-‐LD standard, and is implemented using Blackboard, which is the University of Seville institutional web based Learning Management System (LMS). Design and implementation results are presented and analyzed, and some benefits of using IMS-‐LD are remarked.
1. Introduction Learning Design (LD) specification aims at representing the 'learning design' of 'units of learning' (UoL), in a semantic, formal and machine interpretable way (Koper & Olivier, 2004). A UoL may be any instructional or learning event of any granularity, e.g. a course, a workshop, a lesson or an informal learning event. A 'learning design' is defined as the description of a teaching-‐ learning process that takes place in the UoL (Griffiths et al., 2005). The key principle in LD is that it represents learning activities and support activities that are performed by different persons (learners, teachers) in the context of a UoL. These activities may refer to different learning objects that are used in the performance of the activities (e.g. books, articles, software applications, pictures), or they can refer to services (e.g. forums, chats, wiki's) that are used to contribute to the teaching-‐learning process (Griffiths et al., 2005). The Learning Design specification can be seen from (at least) four different perspectives: (1) An educational modelling language; (2) an eLearning methodology; (3) a set of applications; (4) and an interoperability specification (Burgos & Griffiths, 2005). This specification has been developed to meet some specific requirements: Completeness, Pedagogical expressiveness, Personalization and Compatibility (Koper, 2006). In the Computer Architecture Department of the University of Seville (US) in which the that subject is taught, completeness and pedagogical expressiveness are considered key issues. Additionally the new European Higher Education Area (EHEA) promoted by the Bologna process demands innovative pedagogic approaches, and IMS-‐LD may support them.
72
2. Design of the learning scenario The LD specification consists of several components, one of them being the IMS Best Practice and Implementation Guidelines (IMS-‐BPIG, 2009). According to those guidelines, the design and development of education is an incremental process that systematically follows the stages of analysis, design, development, implementation, and evaluation. The following steps are to be taken in order to proceed from a description of an educational problem to a learning scenario: 1. The analysis phase should result in a didactical scenario that is captured in the form of a narrative. 2. The narrative of the analysis stage is taken and cast in the form of a series of (nested) UML activity diagrams. The UML diagrams capture the workflow aspects of the narrative. 3. An XML document instance for the UoL will be put together on the basis of the UML activity diagrams. Any XML document instance should be valid against the LD Specification. Using IMS-‐LD solely as a methodology involves steps 1 (analysis) and 2 (design). The corresponding roles description and an example of UML activity diagrams are presented below. Contents: There are three UoLs: Introduction to Computer Systems, User Interface Design, Algorithmic & Programming. Those three parts allow the students to develop basic competences and skills in the first semester of the first level of the Industrial Design Engineering degree. The number of students is up to 220 split in two groups for theoretical classes, and in four groups for practical classes. That means there are more than 50 students per teacher in the practical classes. That huge amount of students makes difficult to innovate teaching practices for the whole subject. Therefore: the first UoL was taught according to an instructional single-‐learner pedagogic model; the second UoL was based on a problem based learning scenario in which students were working in groups; and the third UoL was approached in a mixed way: working in pairs in face-‐to-‐face sessions, but with a single-‐learner evaluation. For the purposes of the current paper the second UoL is analyzed in detail, because using the IMS-‐ LD specification as methodology is specially interesting for collaborative learning scenarios. Roles and activities are described for User Interface Design Case Study (CS). Roles: Teachers’ roles: •
Facilitator (FA): In principle, all the teachers (three in that subject) play the role of FA, stimulating students in their social-‐constructivist experience. So, the terms teacher and facilitator can be considered equivalent.
•
Coordinator (CO): One of the facilitators will play the CO role. The coordinator has to design the CS description.
•
Evaluator (EV): At least, one of the facilitators will play the EV role. The evaluator is responsible for assessing and evaluating groups and individual proficiency. Nevertheless, FA is also partially involved in the evaluation.
The afore-‐mentioned teachers’ roles can be played by the same or by several persons. For that subject taught at Industrial Design Engineering, one teacher was the CO, and the three of them were FA and EV in their respective classes. 73
Students’ roles: •
Student (ST): In principle, all the students play such a role. But, in order to promote organizational skills, other roles are taken into account.
•
Chairperson (CP): On behalf of the entire group, he/she is in charge of the communication with external partners (other groups’ CPs and the FA). The chairperson, the spokesperson for the group, is responsible for recording key group decisions, and the chosen representative must be appointed as such by the facilitator. This role implementation also benefits the FAs, because it scales the communication workload between students and FAs.
•
Speaker (SK): He/she is the person who must present the outcomes of the final CS solution in the corresponding final face-‐to-‐face session. He/she must also discuss with the rest of the CPs and SKs at this session.
Activities: The activity dynamic is described by using UML diagrams. A few of them are shown in current paper: Global learning scenario (fig.1), and the rest of them (fig.2, 3 and 4) corresponding to UoL2: User Interface Design Case Study.
Fig. 1: Global Learning scenario. The Global Learning Scenario is composed of several activities. The first two are preparatory work (designing learning and content by all the teachers coordinated by the CO role), and logistic tasks (corresponding to the starting of the teaching activity at the beginning of the semester; they include creating group of students and assessment activities).
74
Fig. 2: UoL2: User Interface Design Case Study. In relation to the UoL2 (see fig. 2), there were two milestones. The first one was scheduled to promote learners to work hard in the CS since the very beginning. Once the initial milestone delivery took place, there were no other marked milestones until the end, which happened at the end of the fifth week, just before the final face-‐to-‐face session. In the final milestone evaluation & feedback all the teachers were involved. In some groups, the EV role was played by a different person than the usual FA role. In other groups both roles were played by the same teacher. Students’ work in groups (see fig. 3): Every student in the group reads the problem (by downloading the corresponding PDF documents from the LMS). The group then meets up (they may use synchronous or asynchronous facilities of the LMS) and discuss how to clarify the problem and plan work scheduling. They eventually arrive at their own succinct statement of the problem at hand. Once this is done, the CP states the problem, and interacts with the FA to clarify open issues and agree on a work schedule. Students can use any communication tool available in the LMS, (e.g. chat, email,…) It is important to note that, in order to scale teacher-‐student interaction, on one hand students only communicate with the FA via the CPs and, on the other, the FA creates a FAQ (frequently asked questions) list published in the LMS containing the most popular and interesting issues arising from the interaction with CPs. Then the CP states the discussed solution and uploads it to the LMS before the deadline. All the CPs discuss the different submitted solutions (via the LMS). In the meantime, the FA reads the solutions and monitors CPs’ discussion. (by using synchronous tools –e.g. public forum, and asynchronous tools – such as email) 75
Fig. 3: Students’ work in group. Face-‐to-‐face session (see fig. 4): The CPs discuss other groups’ solutions. Helped by the rest of the students from his/her group, the CP can defend or even rectify their solution. CPs can also ask the FA about issues that have arisen. At the end of the discussion, the FA provides assistance, clarifies, gives some support for further work and finally gives some feedback on group and individual progress.
Fig. 4: Face-‐to-‐face session.
3. Results after implementation of the learning scenario Three types of evaluation are being taken into consideration to detect the pros and contras of the proposed method: 1. Students’ opinion 2. Teachers’ opinion 3. Students’ marks During the first semester, the three teachers involved in the subject did several interviews to 76
collect students’ opinions. Interviews were done to random selected students (during some minutes in the face-‐to-‐face sessions). All the interviews were very positive because students pointed out the advantages, but also the main difficulties to carry out with this subject. The most interesting were the opinions of students who abandoned the subject the previous year. Some of them stated: “weekly milestones suppose more workload during the semester but encourage us to follow the subject”; “doing a task to deliver a document makes us to understand the objective of the UoL”; “evaluating not only knowledge, but also the competencies is a more fair evaluation procedure”. Of course students give their bad/good impressions about working in group; in fact most students were not skilled in this capacity, so usual problems were detected in some groups. Furthermore an opinion test composed of ten questions has been prepared to collect a more statistical result. This test is going to be asked during the last part of the second semester by the University of Seville services. It was not undertaken before because the aim is that student compare that subject pedagogic method with the rest of the subjects they are studying in the current academic year . For this reason this result is not available yet. With respect to teachers’ opinions, all of them think that workload has to be measured for the next course. During current course the high amount of changes introduced in the methodology made difficult to calibrate the different workloads. Due to the fact that all the teachers were involved deeply in those changes, the particular opinions were very subjective and not relevant for the moment. For the next course, we are considering that teachers’ opinions should be collected by an external agent. Finally marks for students are considerably better than those of previous year counterparts as it is shown in fig. 5. It is obvious that the methodological change has had a positive impact in the marks. We think that a key issue had a main influence in marks: students motivation due to the weekly guidance and feedback. In fact much fewer students have abandoned the subject during this year (36% while the abandon rate was huge during previous year, 76%). Another question that might have a positive impact is the renovation taken in terms of content. While statistical tests are not yet available, students’ interviews told us that this last factor was not crucial.
Fig. 5: Students’ marks: semester 2007-‐2008 (left), semester 2008-‐2009 (right).
77
4. Benefits of using IMS-‐LD Some benefits of adopting IMS-‐LD in a traditional Higher Education (HE) institution are: 1. It promotes the use of role models to support a distinction between possible roles and real actors. Explicit distinction between roles addresses the division of responsibilities improving coordination and supporting tasks, and making solution easily scalable regardless of number of involved teachers. 2. It promotes the structuring of activities such as preparatory work, logistic tasks, sequential activities, etc. Therefore the process dynamics –which is a key issue in the teaching/learning experience–, is made explicit. Moreover it helps to distinguish between learning and support activities. Although it is usual to take into account such a distinction, it should be made explicit in the pedagogical design from the very outset to prevent the coordinator from becoming overloaded. 3. Allocation of resources and environments is also made explicit when designing a pedagogical scenario using IMS-‐LD. In this way, it is easier to think in terms of scalability and feasibility when allocation is clearly defined from the outset. 4. Reusability of learning design is promoted. Of course, teachers must review designed and implemented scenarios to adapt them to the new performance or subject. But design and adaptation costs are estimated to be very low once the course or UoL has been designed and implemented. 5. To schedule teaching and learning activities in design time promotes quality improvement, although it is usually necessary to do further adjustments in implementation time (i.e. when the students are already involved in the course). 6. If the long run, once we have used the LD methodology for a substantial period of time, it should be possible to extract pedagogical patterns that help teachers identify the best teaching and learning practices, assisting academic community with reporting and performance analysis. This outcome should have a clear potential benefit that must be considered when adopting a corporative strategy for innovation purposes in educational practices.
5. Conclusion On one hand, the teachers involved in this trial have concluded that the IMS-‐LD specification is a very useful methodological tool for formalizing the design of pedagogical scenarios. In fact, they have used the methodology included in the IMS Learning Design Best Practice and Implementation Guide (IMS-‐LD BPIG, 2009), as it is explained above. On the other hand, some important drawbacks regarding with using IMS-‐LD were identified, and some decisions were taken, as follows: •
Teachers working in the department are willing to innovate their teaching practices, as long as the increase in their workload is kept to a minimum. As they have to combine teaching and research activities, additional workload of using learning standards must be minimized. Additionally a very high level of detail (related to a granularity of specification) is required to make a machine-‐readable version of a UoL. Bearing in mind these issues, a good solution is to use IMS-‐LD just as an e-‐learning methodology. That means that using that specification makes sense although development and implementation stages are 78
missing. •
The initial effort needed to create a pedagogical scenario using that specification is likely to be greater than a situation when teachers think in terms of content and split responsibilities among them. But the return of the time investment is achieved soon, in the next semester. Moreover it is also possible to compensate individual efforts by distinguishing the “learning designer” role to compensate additional workload between teachers.
References Burgos, D., Griffiths, D. (2005). The UNFOLD Project: Understanding and Using Learning Design, Open University of The Netherlands, 25-‐30. Griffiths, D., García-‐Robles, R. et al (2005). Learning Design, Springer-‐Verlag, 109-‐135. IMS LD Information Model, pp 71, www.imsproject.org IMS LD Best Practice and Implementation Guide www.imsglobal.org/learningdesign/ldv1p0/imsld_bestv1p0.html Koper. R., Olivier, B. (2004). Representing the Learning Design of Units of Learning, Educational Technology & Society, 7 (3), 97-‐111. Koper, R., (2006). Current Research in Learning Design, IEEE Journal Educational Technology & Society 9 (1), Special Issue on Learning Design, 13-‐22.
79
Devising instruction from errors in students’ assignments: a case in usability engineering education Elena García-‐Barriocanal, Miguel-‐Angel Sicilia, Salvador Sánchez-‐Alonso, Daniel Rodríguez Information Engineering Research Unit Computer Science Dept., University of Alcalá Ctra. Barcelona km. 33.6 – 28871 Alcalá de Henares (Madrid), Spain {elena.garciab, msicilia, salvador.sanchez, daniel.rodriguezg}@uah.es
Abstract Problem-‐based learning emphasizes the role of problem solving as the main driver of instruction, thus critically relying on the quality of problem collections, which should exercise especially those aspects students find difficult to master. In areas in which extensive and tested problem collections are not available, it is useful to analyze the mistakes of students in previous year’s assignments as a source of evidence for the design of new problems or tutorial resources. This paper reports preliminary results of that approach as applied to heuristic usability evaluation in the context of an introductory Human Computer Interaction course. The process is described, and some examples are reported as concrete cases in which assignment analysis lead to insights for devising instruction.
1. Introduction Problem-‐based instruction has been subject to significant research interest in recent years (Merril, 2007). Problem-‐based strategies share as a central concern the design of problems that cover the complete spectrum of knowledge and abilities to be mastered, even though they vary in the amount of learner support that is provided and the degree of collaborative activity required. Problems can be defined as “questions rose for inquiry, consideration, or solution”. Instructors facing problem design for their courses attempt to craft problems to support competency development, thus trying to anticipate the “problems in solving the problems”, i.e. facing students with exercising most of the potential difficulties they would find in performing realistic work activities. This can be approached from the experience and sound knowledge of the instructions about the topics to be taught, self-‐reflecting on potential difficulties and pitfalls. In some disciplines, it is easy to find problem collections in textbooks or on-‐line learning resources that can be used as a form of sedimentation of practical experience in proposing and evaluating problems. However, there are topics or disciplines for which few or fragmented problems collections are available, and in general problem collections do not provide hints on the kind of learning difficulties and detailed topic coverage of each of the problems they contain. In those cases, an empirical approach would be helpful to continuously improve and evolve problem collections. Empirical data on problems faced by students can be gathered from the assignments in previous courses. The careful examination of assignment solutions given by students is the best source of evidence for devising new problems or updating existing ones, if we assume that student cohorts are reasonably homogeneous from one year to the next. Human computer interaction (HCI) is a multi-‐disciplinary area of study that is essential in the education of engineers dealing with the construction of man-‐machine interfaces (Rozanski and Haake, 2003). One of the key competencies to be acquired in HCI is usability evaluation. Usability evaluation requires in general analysis skills and critical thinking, as usability problems are often a matter of degree, and knowledge on usability is described in terms of generic rules (usability 80
guidelines), principles or heuristics that require judgment and practice to be mastered. There exist various techniques for evaluating usability depending on available resources (time facilities and resources), evaluator experience, ability and the stage of development of the software under review (Hartson, Andre and Williges, 2001). It seems apparent that problem-‐based approaches to instructional design may be adequate for teaching usability evaluation. However, such approaches require a carefully devised set of problems that provide the required progressive scaffolding (Simons & Klein, 2007). Skov and Stage (2005) reported a study comparing problems found by students using a conceptual tool with students not using it and with the evaluation outcome of the teachers. The use of the tool resulted in more problems found by students, which supports the idea that additional scaffolding elements are required for usability evaluation. The elaboration of case collections for usability engineering has been approached by Carrol and Rosson (2005). These are comprehensive cases that fit project-‐based education, but there is a need to understand and learn to apply the concrete guidelines and heuristics related to expert-‐based usability evaluation, as these can provide detailed insights on how students face usability problems. This paper reports preliminary results of an ongoing comprehensive study on problems found by students when approaching inspection methods for usability evaluation, concretely, heuristic evaluation. Heuristic evaluation is a problem-‐oriented usability evaluation method (Nielsen, 1992). In its initial proposal by Nielsen and Molich (1990), it was found that it served to identify 55 to 90 percent of the known usability problems user interfaces, concluding that heuristic evaluation was a cheap and intuitive method for evaluating the user interface. Heuristic evaluation has an additional interesting property in the educational context: it forces students to classify usability problems, assess their importance and argument why they qualify as such. Consequently, the analysis of records of student heuristic evaluation has the potential to uncover underlying false assumptions, misunderstandings or in general difficulties in acquiring user interface evaluation abilities. The rest of this paper is structured as follows. Section 2 describes the context of the case reported here and the data gathering procedures. Section 3 provides the results of evaluating a small sample of users and discusses these preliminary findings. An example of instruction design from the analysis of assignment data is provided in Section 4. Finally, conclusions and outlook is provided in Section 5.
2. Context and data gathering The ACM/IEEE/AIS curricula recommendations for Computer Science include 8 core hours of Human-‐Computer Interaction, which is concerned with the required skill of “knowing how to create a usable interface and testing the usability of that interface”. In the detailed topics related to HCI, the recommendations include “evaluation without typical users”, including guidelines, heuristics and expert-‐based analysis. While user testing is considered the most reliable way of evaluating user interfaces, teaching guidelines and heuristic evaluation have the benefit of not requiring students to be provided with an observational setting, so that distance students are able to exercise that kind of evaluation. Further, such kinds of evaluations do not rely on the availability of users for testing, but on the application of theoretical elements and guides. If these elements are used for summative assessment of students, the student’s responses can be evaluated rather objectively by instructors. The context of the present case was an elective course on Human Computer Interaction at the last year of a four-‐year degree in Computer Science. The authors had been teaching the course since 2004 following a continuous assessment method. The course starts with an HCI fundamentals module, followed by a module on user interface design and then a usability evaluation module. 81
Students are taught about user testing, but also other methods including heuristic evaluation. One of the assignments included in the continuous assessment presents the students with concrete Web sites for heuristic evaluation, following Nielsen’s heuristics and rating scales. Students have previously exercised the technique at an heuristic evaluation lab, and they are equipped with knowledge on guideline-‐based assessment as a supplementary tool6. The users have to report on problems found as exemplified by the Table 1 entry. Table 1. Categories for problems, severity and error description in problems found. 0
Severity 1 2 3
VSS
X
UCF
Category
4
Error description
The Web site is too much interactive Some pages linked from the homepage have no option X to go back or this option is difficult to find.
Categories for problems are the following: visibility of system status (VSS), Match between system and the real world (MSRW), user control and freedom (UCF), consistency and standards (CS), error prevention (EP), recognition rather than recall (RRR), flexibility and efficiency of use (FEU), aesthetic and minimalist design (AMD), help users recognize, diagnose, and recover from errors (HURE) and help and documentation (HD). Hvannberg, Lai-‐Chong and Larusdottir (2008) found no significant differences between using Nielsen’s heuristics and the cognitive principles of Gerhardt-‐ Powals, and no difference was also found in either using a web tool or paper, so we have not initially not considered these variables in the design of the study. The analysis of assignments requires a detailed representation of problems found versus actual problems (as identified by the instructors), an analysis of the appropriateness of the assessment of severity, and the qualitative examination of justifications in the problems found. The data analysis was done by creating a database following the schema depicted in the Fig. 1.
Fig. 1. Database created for data analysis 6
Concretely, they have been introduced at the beginning of the course to guideline-‐based usability analysis using the research-‐based guidelines elaborated by the U.S. Department of Health and Human Services available at: http://www.usability.gov/pdfs/guidelines.html
82
Table Students recorded information on the students evaluated, the academic year in which they took the HCI course, the site they evaluated heuristically and their overall grade in the course (score). Then, each of the problems identified by students is recorded in the problemsFound table, including severity assigned, Nielsen category selected, and the related guideline(s) identified (if any). The instructors filled the Error field, classifying entries in which students failed to justify the reason of the problem, or simply reported a situation that was not actually a usability problem. Problems found that were actual problems are related to the Problems table, which stores the “correct” problems, categories and severity ratings. Matching problem found descriptions was done by the instructions, even though matching problems has been found to be controversial across matching techniques (Hornbaek and Frokjaer, 2008), here the group and criteria are homogeneous, and they are built by the same matcher.
3. Discussion A sample of the problems found by five students (related to the same target web site) was used as a first application of the analysis method. A total of 82 problems were found by the students, of which 31 were correctly identified problems. Despite the apparent high error rate of this figure (below 50%), it represents a common situation, as there is in general a high dispersion in actual problems found, pointing out that there is some barrier for some students even to identify some prominent problems. This suggests general misunderstandings of usability problems, as confirmed by the qualitative analysis of justification reports. For example, the student with Id 5 reported a total of 31 problems, of which only 11 matched actual problems. Nonetheless, from the other 20 problems, 10 of them were incorrect because they are considered redundant statement (see section 4), that is, very related or identical to problems already detected. For example the student detected that there is no a link to the homepage in 4 pages and reported 4 different errors. There were other 3 reported errors that are considered as partially mistakes because they are very vague descriptions of errors or very subjective (and obvious) opinions (see in section 4 ‘vague statements’). Severity assessments in properly identified problems were identical to instructor assessments in only 13 cases, however, relaxing the coincidence in plus/minus one severity point, the figure was 21 out of 31, which represents a reasonable fit given that severity ratings entail a degree of subjectivity associated with the identification of priorities in fixing errors.
4. Elaborating problem statements from data Evidence gathered from student assignments can be used for developing new assignments and also for the development of guided problems that are targeted to raise difficulties found by students in the past. This requires a categorization of mistakes found. In the sample discussed above, errors were classified in three categories: incorrect, redundant and vague statements. Redundant statements entail the repetition of the same problem found in several sections of the Web site. This adds nothing to the heuristic evaluation report and should be avoided. This frequent error category reveals a methodological mistake, which can be avoided easily by emphasizing the unique nature of problem entries in the report. In this case, a clarification about redundancy was included in the heuristic evaluation report given to students, and an example emphasizing that aspect was also included in the case presented at the lab, which is discussed with the tutors. 83
Vague statements in contrast represent a very broad category, including statements that are to some extent correct, but fail in accurately describing the problem form a usability perspective or even use clichés and stereotypes. Examples of these statements are “the page is too interactive” (supposedly referring to the impossibility of avoiding animation, i.e. a lack of user control) or “the consistency of contents and interfaces is poor” (which fails in detailing the concrete inconsistent elements, e.g. navigation structures, general appearance, etc.). Those reported errors that don’t reflect real usability problems are considered incorrect statements. Examples of incorrect statements are “The site is not WAI compliant” or “In page X there is no link to homepage” when it exists. Although statements like the last one can reflect usability problems, they are considered as errors in the assessment of a report on heuristic usability evaluation. Once the errors reported by students have been analyzed, teachers can fine tune the problems (examples and lab practices) to reflect in usability evaluation case studies most common misunderstandings. To do so, found errors can be grouped by heuristic. After explanations of most common errors by heuristic, the students must evaluate examples and counter examples implemented ad-‐hoc as prototypes which reflect those errors. The learning process can be strengthened planning user interface design problems in which students had to reflect explicitly how to deal with that kind of errors.
5. Conclusions and outlook Problem-‐based approaches to instruction rest in the careful design of problems or cases that are used both for tutoring and evaluating students. Some topics lack reliable, mature problem collections that could be used by instructors as a point of departure. In these cases, evidence can be gathered form student assignments involving problem solving, so that new or revised problems can integrate aspects known to have been difficult to master or sources of common errors in their statement and task design. This paper have reported on the preliminary results of that technique applied to gaining insight on student’s difficulties and pitfalls when confronting heuristic usability evaluation. The procedure entailed a detailed analysis of problem report entries submitted by students and their categorization, leading to three broad categories of error that entail different kinds of update of teaching material. Future work will cover a detailed analysis of the database of at least two student cohorts in the HCI course, and a comprehensive account of potential sources of error and the problem design guidelines that follow from them.
Acknowledgements The research is within the framework of the activity of the educational innovation project UAH/EV243, from University of Alcalá.
References Carroll, J. M. and Rosson, M. B. 2005. A case library for teaching usability engineering: Design rationale, development, and classroom experience. J. Educ. Resour. Comput. 5, 1 (Mar. 2005), 3. Hartson, H.R., Andre, T.S. and Williges, R.C. (2001) Criteria for evaluating usability evaluation methods, International Journal of Human–Computer Interaction 13 (4) (2001), pp. 373–410. 84
Hornbaek, K., Frokjaer, H. (2008) Comparison of techniques for matching of usability problem descriptions, Interacting with Computers, 20(6), pp. 505-‐514 Hvannberg, E.T., Lai-‐Chong, E., Larusdottir, M.K. (2008) Heuristic evaluation: Comparing ways of finding and reporting usability problems, Interacting with Computers, (19)2, pp. 225-‐240 Merrill, M.D. (2007) A Task-‐Centered Instructional Strategy. Journal of Research on Technology in Education, 40(1), pp. 33-‐50 Nielsen, J. 1992. Finding usability problems through heuristic evaluation. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (Monterey, California, United States, May 03 -‐ 07, 1992). P. Bauersfeld, J. Bennett, and G. Lynch, Eds. CHI '92. ACM, New York, NY, 373-‐380. Nielsen, J., and Molich, R. (1990). Heuristic evaluation of user interfaces, Proceedings of the Conference on Human Factors in Computing Systems (CHI 90), Seattle, WA, April 1-‐5, pp. 249-‐256. Rozanski, E. P. and Haake, A. R. (2003). The many facets of HCI. In Proceedings of the 4th Conference on information Technology Curriculum (Lafayette, Indiana, USA, October 16 -‐ 18, 2003). CITC4 '03. ACM, New York, NY, pp. 180-‐185. Simons, K. and Klein, J. (2007). The Impact of Scaffolding and Student Achievement Levels in a Problem-‐based Learning Environment. Instructional Science, 35(1), pp. 41-‐72. Skov, M. B. and Stage, J. (2005). Supporting problem identification in usability evaluations. In Proceedings of the 17th Australia Conference on Computer-‐Human interaction (Canberra, Australia, November 21 -‐ 25, 2005). OZCHI, vol. 122. Computer-‐Human Interaction Special Interest Group (CHISIG) of Australia, Narrabundah, Australia, pp. 1-‐9.
85
This document was finished in Cádiz, 13 of April of 2009
ISBN 978-‐84-‐692-‐3450-‐1
86
Related Documents
Mcce 2009 Proceedings
April 2020 2
Mcce 2008 Proceedings
November 2019 4
Proceedings
December 2019 23
Proceedings
December 2019 27
Proceedings
May 2020 14
Ictd 2009 Proceedings
April 2020 5More Documents from ""
Mcce 2008 Proceedings
November 2019 4
Mcce 2009 Proceedings
April 2020 2
Resolucion_00929_1987.pdf
April 2020 2
Cantos De Adviento 2009
June 2020 4
