close

Вход

Забыли?

вход по аккаунту

?

HOW TO TEACH PROGRAMMING PRACTICES Introduction The

код для вставки
HOW TO TEACH PROGRAMMING PRACTICES
RICHARD BALOGH
Abstract. Author is involved in the teaching the basic course Architecture
of computers. We describe our experiences about the teaching the basic programming techniques in the C language. Organisation of exercises, problems
and difficulties during the realisation, feedback from the student side is mentioned. We mention also our experiences with an evaluation of the originality
of students work.
Introduction
The growing importance of information systems, and their use to support everyday life, has made information knowledge a central issue for modern technical
education. The Computer Architecture course introduces the technical foundations
of computer components. The main objective of the course is to understand their
underlying principles.
Computer Architecture course is the part of the bachelor studies at the Slovak
Technical University in Bratislava, Faculty of Electrical Engineering and Information Technology (FEI STU) for many years. Unfortunately, classical view to this
course with focus on microprocessors, its internal architecture and microcodes was
not satisfactory for the majority of students. So we try to modify that course for
a larger target group, to give the freshmens broader view to computers, the tools
they will use heavily in everyday life.
1. Organization
Computer Architecture is an obligatory course for all study programs at the FEI
STU. The classification is based on work during the semester (40%) and results of
the written final exam(60%). We meet once a week on lectures (3 hrs/week) and
students also work in a computer lab (2 hrs/week). Besides the approximately 500
daily students we teach also approximately 50 ones in a distance form of study.
Usually students are organized into the 26 - 32 groups with 18-20 students in each
of them. Lecture is where introductions to the main topics are made as well as
different historical roots and contemporary state of the art. Images and many
demonstration materials are incorporated for preview and review.
Topics covered in the course include basic concepts of computers, flow of instructions, data representation, binary systems, basics of digital systems, the concept
of processor, memory and storage subsystem, input and output subsystem, single
and multiprocessor systems, data buses, matrix processors and computer networks,
operating systems.
1991 Mathematics Subject Classification. K3.2; C0, D2, J2, K5.1.
Key words and phrases. architecture of computers, programming, education, cheating.
This work was supported by the grant KEGA 3/5201/07.
1
2
RICHARD BALOGH
Figure 1. Course wikipage with lecture material.
The course assumes no previous knowledges, but basic skills with operation of
computers is assumed as well as an elementary mathematics background.
The primary objective of the course is to learn the fundamental principles underlying digital computers and computer networks. Using a down-top approach, we
cover topics in the single- and multi-processor systems, let the student understand
the principles of the main computer subsystems – processor, inputs and outputs
and memories and storages. We try to give the understanding as well in engineering
tradeoffs made and design principles used in computers and networks.
During the semester, 12 lectures covers the following topics:
(1) History. Foundations of digital computers. Harvard vs. von Neumann
architectures. Classification and generations of computers.
(2) CISC and RISC architectures. Types of memory. Memory management
and protection.
(3) Representation of an information in the computer. Digital representationof
information. Data types, numeric and character codes. Basic arithmetical
operations. Numbering systems. Floating point numbers.
(4) The basic building blocks of the processor. Operational and control parts
of the processor.
(5) Instruction set. The types of instructions. The format of instruction. Instructions for work with computer memory. Addressing methods.
(6) Computer bus. Data bus, address bus, computer architecture. Uniprocessor and multiprocessor buses, arbitration, access, multiplexing. Examples
of standards.
HOW TO TEACH PROGRAMMING PRACTICES
3
(7) Memories. Internal and external, addressing, DMA, cache. Fixed and
removable media.
(8) Inputs and outputs. Parallel port. Input and output logic values. A/D and
D/A converters. Industrial control computers. Electromagnetic compatibility (EMC).
(9) Interrupts, resources and interrupt service. Counters and timers. Real
time.
(10) Serial interfaces. UART, USB, industrial standars. Graphics, graphics
card.
(11) Computer networks. Network media. The message, framework, packet.
(12) Operation system and its functions.
There are usually between 450 and 550 students registered. Last year the course
was organized for 450 students of the first year. The course is finished by the
final exam, which was quite successful last time. Only 35 students of those who
participated the exam did not pass (see Fig. 2).
Figure 2. The exam 2009
2. Exercises
The lectures are incomplete without the appropriate laboratory exercises. In
the past, the Computer Architecture exercises were concerned on internal structure
of microprocessors and lot of work with microcodes. We tried to broaden the
view and because the large amount of students together witg a limited access to
the technology required, we remain on the C-programming level. The exercises
follows-up the ones from the previous semester, where students get in touch with
C language. In our labs we focus on the programming of the different components
of the computer.
We have an access to the computer laboratory, equipped with the Microsoft
Visual C++. Different compilers are allowed, but not supported. Exercises are
organized in three four-weeks blocks. Each block contains a set of tasks required to
be solved. There is just minimum 5 points required, it is the students responsibility
to choice which tasks to solve and how many points to obtain.
Students are required to work individually during the semester and submit their
own programs. Programs are organised into the three blocks. First block deals
with numbers and its representation in computer, second block is hardware oriented
4
RICHARD BALOGH
and last block requires to program small project, relatively large compared to the
previous tasks.
2.1. Block 1: Number representations and operations. First block is more
numerical. Very first task is to program the "classical" decimal to binary code
converter. It is a starter, to repeat the skills from the previous semester, for some
students offers a possibility to understand the recursive algorithms. Another tasks
in this block deals with the different data types and their ranges, float numbers
with fixed and floated decimal point and one task deals with the machine epsilon.
More difficult tasks include computation of goniometric function using the Taylor
series. One task deals with the checksum calculation and overflow.
The typical task from this block is to find a machine epsilon for different data
types. Even this task looks easy, it sometimes brings student to deeper knowledge
of the compiler optimization and operation of the GPU. Standard student’s solution
while ( (1 + Epsilon/2) > 1.0)
instead of more appropriate
while ( Sum > 1.0 )
{
Sum = 1.0 + Epsilon;
...
is usually compiled with register variables and thus increasing the resolution of the
floating point arithmetics to the more than 64-bits.
Figure 3. The course website
Students consider this block usually quite easy but not very attractive. Unfortunately, the lectures are not optimally synchronized with exercises, so students
without prior knowledges are sometimes lost in problems.
HOW TO TEACH PROGRAMMING PRACTICES
5
2.2. Block 2: Computer peripherals. Second block is more hardware oriented.
The tasks covers all computer components and peripherals. In this block we introduce also an assembler as an easy way how to write the processor oriented code.
Even this sometimes brings a serious headache to the students, we limit the number
of assembler instructions to the number of 10 and added a detailed description at
the course web page. To make the task even easier, we are not considering the
problems with operation system interaction. Instead, we use an in-line assembler
as a part of the C-program, so the program calls, interfacing with the operating
system and other problems are hidden for now. This avoids needs for a special
start code, deeper knowledge of the operating system structure etc. Programs are
then simulated step-by-step using the MS Visual Studio debugger, to move closer to
the registers, memory areas and processor itself. Even more, students are provided
with the sample program, so their task is in fact just to change some instructions
in already operating program.
This set of tasks is considered difficult, especially by the students without prior
experiences within this area. To improve the understanding, here is required also
the debugging, stepping and variable watching during the program evaluation.
Figure 4. Debugging the assembler problem
Another typical problem from this block is to make some semi-graphics window
in the console window (see Fig 5). Results of this simple task can be later reused
in the more complicated problems.
This block is usually evaluated by the students as more complicated than previous one, but much more interesting and attractive. The evaluation is based on the
students questionnaire at the end of the semester.
2.3. Block 3: Project – serial communication terminal. Last 4 weeks of
the semester belong to the more complicate problem. Instead of set of problems,
students are required to write a more complex application: simple communication
6
RICHARD BALOGH
Figure 5. Juggling with semi-graphics.
program for talking between the two computers interconnected by the serial line.
First, the problem is decomposed to the set of principal tasks: to open the communication channel, to set its parameters, to send a char, to receive the char and to
close the link. Students are provided with program excerpts for this basic routines,
so their task is just to connect them into the whole application. Even that, many
problems arises. The programs are not communicating with the same parameters,
the cable is not at the same port on different computers, programs are particularly
user unfriendly etc.
Figure 6. Example solution
3. Infrastructure
The computer laboratory consists of 40 standard personal computers with an
Intel Pentium 1,2 GHz processors. They are networked and require login and password identification of the user. Each computer contains Microsoft Visual Studio
installed, but MSDN and help works only with problems, but this can be overcome
by the direct search in MSDN database through the Internet. One problem which
fully appears this year is related with the fact, that more and more students come
to the lab equipped with personal laptops. This may in the future help the university to break its dependency from the new hardware. It was very frustrating,
HOW TO TEACH PROGRAMMING PRACTICES
7
when it was necessary to spend money for the complete computer renewal at each
5-6 years. But for now, it requires the small changes in the lab to make possible to
use the students personal laptops.
Figure 7. Inside the computer lab.
The students are provided with a comprehensive set of study materials. All the
presentations from the lectures are available, also the set of explanation materials
for exercises is available, to enable unsynchronized operation during the semester.
For this purpose we have a dedicated server, located in the Computer center of the
FEI STU. It is used a Acer Altos G330 Intel Pentium D 925 computer (3.0 GHz/800
MHz/2x2 MB), 2x 512 MB DDR2 533 MHz, 2x 250 GB SATAII, DVD-ROM, 2x
Gigabit LAN, 400 W ATX 12V) and 750 VA UPS power source APC UPS SMART
750. The server has installed an Ubuntu Linux with usual packages including the
Apache2, PHP, MySQL, MediaWiki, etc.
All the materials are available from the course website
(http://ap.urpi.fei.stuba.sk/ap).
4. Problems and experiences
During the laboratory exercises, few problems arises: surprisingly, some of the
students simply does not understand English used in the help files. Some students
are too lazy to work by themselves and rather use the others to work on tasks. This
problem can be solved using the program described in the next section.
Evaluation of the exercises is not without the troubles, too. Work of the students
during the semester is evaluated by the teacher on exercises, but we try to make
the evaluation more "standardized" and not to depend on the teacher’s nature. As
shown on the figure 8, there are big differences between the teachers in different
student groups.
The overall evaluation of the lessons by the students (based on the questionnaires) is usually very good (students of the branch Informatics) but it varies up to
8
RICHARD BALOGH
Figure 8. Histogram of the course ranking for two different teachers. Teacher B is too friendly.
the unsatisfactory because a lot of programming (study branch Electronics). But
most of them are satisfied with the conditions, they are considering the evaluation
system is fair, difficulty is balanced and supplementary materials are valuable.
Another problem is, that even we are quite satisfied with the above course organization for daily students, the system of many small tasks is absolutely unsatisfactory
for the distance students. Each student’s solution should be received (via e-mail
or via web-server), then stored, compiled, checked for functionality, and there is
necessary to write comments to the author. All of this is made during a moment
in peer-to-peer contact with student, but it takes a reasonable amount of time in
off-line operation.
5. Program DIP
During the semester we require from students to work separately and individually. As we mentioned above, it is not real to manually check individual programs
from hundreds of students for the originality of programs. Unfortunately, students
are aware of this and often tries to find the easiest way to pass.
There was a strong requirement for the program, which is able to abstract from
everything what can be added or changed in the code without the effect on its
function (comments, names of the variables, etc.), to focus more on the objects
present in the code instead their names, tolerate swapping some pieces of code.
We get inspiration for this system from Faculty of Informatics, Masaryk University in Brno, Czech Republic, where they developed such program. The program
dip was created as a diploma work [3] and thanks to the Mr. KuДЌera we were able
to test it.
Example:
We analyzed all the 453 files in repository, containing the student’s solution of the
block 3. task. We compared them between themselves each to each. Average file
size was 8959 bytes, varying from 2002 byte (not fully functional program) up to
72kB source code.
Comparison of the above mentioned files, each to each takes 13 min and 8 seconds. Command:
dip --mode=all --limit=99 *.c
HOW TO TEACH PROGRAMMING PRACTICES
9
The test was performed on server Acer Altos G330 with Intel Pentium D 925 processor (3.0 GHz/800 MHz/2x2 MB), and memory 2x 512 MB DDR2 533 MHz, with 2x
250 GB SATAII. This test found 116 matches, but in fact only approximately one
half (cca 50) of them was really the cloned programs. Rest of matches is between
successive version of the same student or simply mistakes of the students.
Another example shows how to compare just last added program with others.
We compared one new program with the remaining 453 files from previous example.
Command:
dip --mode=new --limit=95 3liner.c *.c
We obtained following result after the 26 seconds
processing 3liner.c
... skipped 451 simillar lines
processing wagner.c
processing zboncak.c
---results--3liner.c, 3liner12345.c --> 100%
3liner.c, 3liner.c --> 100%
We can immediately see the complete equivalence with the program itself and with
the previous version of the same student (program with minor corrections of its
function - one item in menu was added)
Social aspects: The main reason for trying to remove plagiarism was the displeasing feelings during the classes. It was very displeasing to stand against the
second, third student trying to pass with the same program. Also in the feedback
questionnaires we usually give at the end of semester, students were frustrated
with the fact, that some of them did all the programs by themselves, spending lot
of time with computer and some of them did pass with replicas and without pain.
This situation did significantly improve after the first block, when they saw some
consequences. Unfortunately, the 3rd block was so difficult for some students, that
relatively large amount of them did try to cheat. But in fact, this precautions were
positively accepted also by the students.
Acknowledgment. Thanks to the Mr. Jan KuДЌera and David OlszyЕ„ski at the
Faculty of Informatics, Masaryk University in Brno, Czech Republic for providing
us with the dip program [3].
The results of this paper were supported by the grant KEGA 3/5201/07.
References
[1] W. Stallings, Computer Organization and Architecture: Designing for Performance, Prentice
Hall, 792 pp., 2009.
[2] M. JelЕЎina, ArchitektГєry poДЌГ­taДЌovГЅch systГ©mov. PrincГ­py, ELFA, KoЕЎice, 2002.
[3] D. OlszyЕ„ski, HodnocenГ­ podobnosti dvou programЕЇ, DiplomovГЎ prГЎce, Faculty of Informatics,
Masaryk University, Brno, 2002.
[4] I. KopeДЌek and J. KuДЌera, ZГЎklady prГЎce s osobnГ­m poДЌГ­taДЌem. Brno : CERM Brno, 1996.
Faculty of Electrical Engineering and Information Technology, Slovak University of Technology in Bratislava, Slovakia
E-mail address: richard.balogh@stuba.sk
Документ
Категория
Без категории
Просмотров
42
Размер файла
1 244 Кб
Теги
1/--страниц
Пожаловаться на содержимое документа