tutaj - EduAkcja. Magazyn Edukacji Elektronicznej

Transkrypt

EduAkcja. Magazyn edukacji elektronicznej
nr 2 (12)/2016, str. 101—113
Skrypty w systemie automatycznej oceny rozwiązań zadań
programistycznych.
Część I. Kontekst i motywacje
Krzysztof Barteczko
Polsko-Japońska Akademia Technik Komputerowych
[email protected]
Streszczenie: System Doskonalenia Kwalifikacji Programistycznych (SDKP), wdrożony w Polsko-Japońskiej Akademii Technik Komputerowych umożliwia nauczycielom tworzenie skryptów, wspomagających ocenę rozwiązań
zadań programistycznych. Specyfikując zadania do wykonania i sprawdzając później ich rozwiązania, nauczyciel
może nie tylko korzystać z rozlicznych wbudowanych w system narzędzi weryfikacji (jak w tradycyjnych systemach
automatycznej oceny), ale również dostarczyć skrypty testujące poprawność wyników oraz jakość kodu. W skryptach można używać bogatych środków przetwarzania informacji, w tym środków statycznej i dynamicznej analizy
kodów programów. Dla nauczycieli przedmiotów programistycznych tworzenie skryptów nie powinno sprawiać
trudności, a przy tym może znacząco poprawiać jakość analizy rozwiązań. W pierwszej części artykułu przedstawiono krótką informację o SDKP na tle innych systemów automatycznej oceny rozwiązań zadań programistycznych oraz główne motywy i założenia użycia skryptów w systemie.
Słowa kluczowe: nauczanie programowania, automatyczna ocena rozwiązań, statyczna analiza kodu, dynamiczna
analiza kodu, testowanie oprogramowania, skrypty, Java, Groovy, metaprogramowanie, analiza AST, refleksja
1. Wprowadzenie. O systemach automatycznej oceny rozwiązań zadań programistycznych
Automatyczna ocena rozwiązań zadań programistycznych jest coraz częściej stosowana w procesie dydaktycznym. Jej początki sięgają lat 60. ubiegłego wieku (Forsythe i Wirth, 1965), a po
2000 r. zaobserwować można znaczący rozwój stosowanych w tym zakresie podejść i narzędzi
(Caiza i Del Alamo, 2013; Douce, Livingstone i Orwell, 2005; Gupta i Dubey, 2012; Ihantola,
Ahoniemi, Karavirta i Seppälä, 2010).
Zapewne pierwszoplanowym motywem budowy i stosowania narzędzi automatycznej oceny
było i nadal jest ułatwienie pracy nauczycieli. Istotnie, manualna ocena poprawności i jakości
dużej liczby programów jest niezwykle pracochłonna. Wsparcie ze strony automatycznych narzędzi (oczywiście, niezastępujące finalnej oceny rozwiązania przez nauczyciela) może tu być
bardzo pomocne.
Jednak wcale nie to powinno być główną zaletą stosowania systemów automatycznej oceny
rozwiązań (SAO). Oprócz ułatwienia oceny, systemy te powinny czynić proces oceny:
• wieloaspektowym (uwzględniającym poprawność, jakość, efektywność oraz elastyczność rozwiązania, a przy tym wykluczającym plagiaty),
• bardziej precyzyjnym (umożliwiając wykrywanie większej liczby błędów i niedociągnięć, niż
ma to miejsce przy ocenie manualnej),
• otwartym (czyli pozwalającym na modyfikowanie i dodawanie procedur automatycznej oceny zgodnie z potrzebami nauczycieli),
Krzysztof Barteczko, Skrypty w systemie automatycznej oceny rozwiązań zadań...
• rejestrowalnym, odtwarzalnym i powtarzalnym (co jest ważne dla doskonalenia mechanizmów oceny oraz zapewnienia porównywalności wyników ich zastosowania),
• przejrzystym i zrozumiałym dla studentów.
W konsekwencji powinna poprawiać się jakość kształcenia: studenci będę lepiej rozumieć
swoje niedociągnięcia i ich przyczyny, dydaktycy – lepiej dostrajać proces dydaktyczny do konkretnych warunków.
Rozwój systemów automatycznej oceny doprowadził do tego, iż znane współczesne SAO –
takie jak np. BOSS (Joy, Griffiths i Boyatt, 2005), Web-Cat (Edwards i Perez-Quinones, 2008),
CourseMarker (Higgins, Gray, Symeonidis i Tsintsifas, 2005), VirtualLab (Rodríguez-del-Pino,
Rubio-Royo i Hernández-Figueroa, 2012), FLOP (Ljana, Martin i Pareja-Flores, 2012), Style++
(Ala-Mutka, Uimonen i Jarvinen, 2004), Petcha (Queirós i Leal, 2012), bottlenose (Sherman,
Bassil, Lipman, Tuck i Martin, 2013), JACK (Striewe, Goedicke i Balz, 2008), AutoLEP (Tiantian, Xiaohong, Peijun, Yuying i Kuanquan, 2009) – w dużym stopniu spełniają wyżej wymienione wymagania.
W dużym stopniu, ale nie do końca. O każdym z nich można powiedzieć, że charakteryzuje
się co najmniej jedną z niekorzystnych cech:
• niekompleksowością – czyli weryfikacją tylko niektórych aspektów rozwiązań (np. tylko poprawności lub tylko stylu albo pominięcie identyfikacji plagiatów),
• zamkniętością – brakiem możliwości uzupełniania przez nauczycieli zestawu reguł testowania/oceny,
• nieadekwatnością – zbyt uproszczonymi sposobami testowania rozwiązań, co uniemożliwia
zastosowanie automatycznej weryfikacji dla szerszego zakresu zadań,
• trudnością użycia – zbyt skomplikowanymi sposobami definiowania przez nauczycieli reguł
testowania.
Omawianie istniejących systemów automatycznej oceny rozwiązań, ani tym bardziej ich analiza porównawcza, nie stanowią przedmiotu artykułu. Dla zilustrowania postawionej wyżej tezy
warto jednak pokrótce przedstawić ich główne cechy, a także słabości w zakresie automatycznego testowania (zob. Tablica 1).
Tablica 1. Główne cechy i słabości popularnych SAO. Uwaga: dane podane w tabeli opierają się na ogólnie dostępnych informacjach, w szczególności z wcześniej przytoczonych artykułów
Nazwa SAO
Główne cechy
(w zakresie testowania)
Słabości
BOSS
Testowanie poprawności rozwiązań za
pomocą porównania faktycznych wyników
z oczekiwanym oraz z użyciem testów jednostkowych (JUnit).
Testowanie stylu rozwiązań za pomocą predefiniowanego zestawu metryk z możliwością
ich uzupełniania przez dodatkowe komponenty programistyczne, opracowywane przez
developerów systemu.
Testy antyplagiatowe.
Ograniczony zakres metryk stosowanych przy
testowaniu stylu.
Wtłoczenie dynamicznej analizy kodu
wyłącznie w (zbyt sztywny) schemat testów
jednostkowych.
Zwykły nauczyciel-użytkownik ma ograniczone możliwości łatwego definiowania
testów (praktycznie tylko w zakresie definiowania wejść i wyjść w testach typu „czarna
skrzynka”).
Testowanie poprawności za pomocą weryfikacji wyników działania programu,
Testowanie stosowania określonych konstrukcji w rozwiązaniach,
Testowanie stylu za pomocą predefiniowanego zestawu metryk.
Ograniczone możliwości konfigurowania
testów poprawności rozwiązań oraz weryfikacji stosowania konstrukcji programistycznych
(tylko na podstawie regularnych wyrażeń, co
znacznie ogranicza zakres ocenianych zadań).
Publicznie dostępne informacje na temat tego
systemu pochodzą sprzed więcej niż 10 lat, co
może oznaczać, że nie jest on dalej rozwijany.
CourseMarker
EduAkcja. Magazyn edukacji elektronicznej, nr 2 (12)/2016 , str. 103
Nazwa SAO
Główne cechy
(w zakresie testowania)
Web-Cat
Opiera się głównie na założeniu, że studenci
sami mają testować swoje programy, a system
sprawdza jakość tego testowania i stopień pokrycia rozwiązania testami; nauczyciele mogą
używać własnych testów, ale tylko w zakresie
testów jednostkowych.
Testowanie stylu/wymagań za pomocą
Checkstyle i PMD.
Mała różnorodność rodzajów testów i sposobów testowania, brak możliwości definiowania testów stylu przez nauczycieli – „zwykłych” użytkowników.
Brak możliwości definiowania testów poprawności na podstawie weryfikacji wyników
działania programu.
Testowanie poprawności rozwiązań głównie
za pomocą weryfikacji wyników działania
programu z dodatkową możliwością użycia
testów jednostkowych (JUnit).
Testowanie stylu rozwiązań za pomocą predefiniowanego zestawu metryk.
Definiowanie bardziej zaawansowanych
testów wymaga od nauczycieli-użytkowników
dostarczania wielu plików w tym skryptów
systemowych, zarządzających technicznymi
szczegółami kompilacji i wykonania testów.
Zdefiniowanie takiego testu jest więc trudne
i pracochłonne.
Virtual Programming Lab
for Moodle 3
FLOP
PETCHA
Style++
Słabości
Testy poprawności rozwiązań za pomocą we- Zbyt mała różnorodność testów.
ryfikacji wyników (praktycznie jest to typowy Zbyt mała elastyczność definiowania dostępprosty system do zastosowania w konkursach nych rodzajów testów.
programistycznych).
Testy poprawności rozwiązań na podstawie
przypadków testowych („black-box”).
Użycie dialektu XML PExIL do definiowania
testów.
Możliwości testowania ograniczone do porównywania wyników z przypadkami testowymi (brak testów wymagań na konstrukcje
programistyczne, testów stylu itp.).
Język PExil – jako dialekt XML – jest niewygodny w użyciu.
Testy stylu predefiniowane w systemie.
Zbyt mała różnorodność rodzajów testów
Nauczyciel ma możliwość wyboru testów oraz (tylko testy stylu).
określenia punktacji.
Brak możliwości definiowania własnych
testów przez nauczycieli.
JACK
Testowanie poprawności za pomocą dynamicznej analizy działania programu.
Testowanie stylu i wymagań za pomocą przetwarzaniu abstrakcyjnych grafów składni.
Sposób specyfikacji przez nauczycieli reguł
dla testów stylu jest uciążliwy i nieintuicyjny.
Brak wbudowanego modułu antyplagiatowego.
AutoLEP
Testowanie poprawności rozwiązań za pomocą przypadków testowych.
Testowanie stylu i spełniania wymagań
poprzez porównanie z rozwiązaniem modelowym.
Testowanie stylu za pomocą porównania
z rozwiązanie modelowym ogranicza różnorodność i złożoność zlecanych studentom
zadań.
Brak wbudowanego modułu antyplagiatowego.
Bardzo elastyczne testowanie wielu aspektów
rozwiązań.
Definiowanie testów wymaga dostosowania
do formatu TAP („test anything protocol”),
co dla niektórych języków (np. Java) oznacza
konieczność poznania odpowiednich bibliotek i dużą pracochłonność tworzenia testów.
bottlenose
Tworząc System Doskonalenia Kwalifikacji Programistycznych PJATK starano się uniknąć
każdej z wcześniej wymienionych słabości.
2. System Doskonalenia Kwalifikacji Programistycznych jako SAO
System Doskonalenia Kwalifikacji Programistycznych (SDKP) zrealizowany został w Polsko-Japońskiej Akademii Technik Komputerowych w ramach projektu PO KL Informatyk – wszechstronny specjalista.
Podstawowym celem SDKP było stworzenie modelu analizy i oceny postępów studentów,
a także zrozumiałego, wspomagającego proces uczenia się, przedstawiania im wyników tej oceny (Barteczko, 2013).
Realizacja tego zamierzenia opierała się w głównej mierze na specjalnie przygotowanych narzędziach weryfikacji rozwiązań zadań programistycznych w języku Java (wybór był podyktowany dominacją tego języka w nauczaniu programowania).
SDKP jako SAO wyróżnia się wśród znanych rozwiązań charakterystykami podanymi w Tablicy 2.
Tablica 2. Wyróżniające cechy SDKP
KOMPLEKSOWOŚĆ
Wykrywanie plagiatów, testowanie poprawności rozwiązań, weryfikacja spełniania postawionych w zadaniu
wymagań, weryfikacja umiejętności stosowania właściwych konstrukcji językowych i bibliotek, sprawdzanie
jakości, stylu, uniwersalności, elastyczności, skalowalności i efektywności kodu.
OTWARTOŚĆ, RÓŻNORODNOŚĆ I ADEKWATNOŚĆ
Możliwość definiowania przez nauczycieli własnych procedur testowania w wyżej wymienionych zakresach,
w bardzo różnorodny sposób, dostosowany do ich wiedzy, umiejętności, upodobań oraz adekwatny do oceny
przygotowanych przez nich zadań.
PROSTOTA UŻYCIA
Łatwość definiowania procedur weryfikacyjnych, nawet dla najbardziej skomplikowanych przypadków niewymagająca od nauczycieli nabywania jakichś nowych umiejętności.
•
•
•
•
Konstrukcja SDKP zawiera następujące moduły weryfikacji-testowania rozwiązań:
PlagTest – moduł antyplagiatowy, wykrywający powielone fragmenty kodów (mechanizmy,
leżące u podstaw działania tego modułu są szczegółowo opisane u (Barteczko, 2012)),
RunTest – moduł, używany do:
–– weryfikacji poprawności działania programu na podstawie porównania jego wyników
z oczekiwanymi; w procesie weryfikacji mogą być stosowane wyrażenia regularne, predefiniowane transformacje faktycznych i oczekiwanych wyników programu oraz zdefiniowane w systemie i/lub tworzone przez nauczycieli skrypty, działające na faktycznych
i oczekiwanych wynikach; jest to główne zastosowanie tego modułu,
–– weryfikacji poprawności programu na podstawie dynamicznego wywołania jego fragmentów (tworzenia obiektów, wywołania metod), a także dynamicznej analizy kodu metodami
tak zwanej. refleksji (Java Reflection API, b.d.), co może być wykorzystywane w ocenie
spełniania wymagań oraz jakości kodu; tutaj stosowane są już wyłącznie skrypty.
BehaviorTest – używany do:
–– weryfikacji poprawności rozwiązań zgodnie ze specyfikacją odnośnie do zachowania programu i jego części (klas, metod); tu stosowane są scanariusze behawioralne zdefiniowane
(w systemie i/lub przez nauczycieli) w postaci skryptów uruchamianych w środowisku
easyb,
–– weryfikacji spełniania wymagań i jakości rozwiązań; tu stosowane są skrypty dynamicznej
analizy kodów środkami refleksji, również uruchamiane w środowisku easyb.
ReqTest – służy do testowania dowolnych wymagań postawionych wobec kodu rozwiązania
zleconego zadania. Przy definiowaniu takich wymagań dydaktycy mogą posługiwać się zarówno bardzo prostymi i łatwymi w użyciu środkami (wyrażenia regularne), jak i bardziej zaawansowanymi sposobami analizy składniowej przy użyciu skryptów, działających na kodach
źródłowych. W skryptach tych stosowane mogą być dowolne narzędzia programistyczne, od
prostych działań na napisach, poprzez wyrażenia regularne, po przetwarzanie drzew składniowych (ang. Abstract Syntax Tree, AST) programów.
• StyleTest – służy do testowanie stylu i koncentruje się na zastosowaniu predefiniowanych
reguł i metryk, sprawdzających wybrane elementy właściwego stylu programowania. W tym
celu z SDKP zintegrowany został znany system statycznej analizy kodu – PMD, przy czym
integracja ta charakteryzuje się ułatwieniami specyfikacji testów, znacząco obniżającymi pracochłonność ich przygotowania przez nauczycieli. Dodatkowo moduł ten umożliwia nauczycielom łatwe dostosowanie istniejących reguł do swoich potrzeb, a także łatwe tworzenie nowych reguł w konwencji PMD; więcej na ten temat zob. w artykule autora (Barteczko, 2015).
• EffTest – służy do testowania efektywności działania programów; wykorzystuje mechanizmy
modułu RunTest dla porównania czasu wykonania programu z czasem wzorcowym i/lub dopuszczalnym.
• UESTest – służy do testowania uniwersalności, elastyczności, skalowalności rozwiązań, integrując wyniki odpowiednio zdefiniowanych testów modułów RunTest, BehaviorTest, ReqTest
i StyleTest.
Sposoby weryfikacji rozwiązań w SDKP podsumowuje Tablica 3.
Tablica 3. Sposoby weryfikacji rozwiązań w SDKP
Zakres weryfikacji 
Sposób weryfikacji 
Kombinacje
predefiniowanych
reguł
Wyrażenia regularne
Skrypty
(w tym scenariusze
behawioralne)
Poprawność
Spełnianie wymagań oraz jakość i styl kodu
analiza źródeł programów i/lub ich AST
analiza wyników programu
z uwzględnieniem różnych
danych wejściowych
analiza źródeł programów
analiza źródeł programów i/lub ich AST
dynamiczna (w fazie wykonania) analiza zachowania
programów
dynamiczna analiza programów środkami refleksji
Weryfikacja efektywności, uniwersalności, elastyczności i skalowalności programów dokonywana jest za pomocą kombinacji narzędzi dynamicznej i statycznej analizy z modułów RuntTest, BehaviorTest, ReqTest i StyleTest.
Weryfikacja rozwiązań studentów wymaga przygotowania odpowiednich definicji zadań.
Składają się na nią między innymi:
• wymagania na strukturę katalogową, nazewnictwo i ewentualnie częściową zawartość plikow
rozwiązania,
• definicje scenariuszy behawioralnych,
• definicje run-testów,
• definicje testów wymagań,
• definicje testów stylu.
Wymagania na strukturę katalogową, nazewnictwo plików, a nawet ich (częściową) obowiązkową zawartość mogą wspomagać wykonywanie testów, choć nie zawsze będzie to konieczne.
Przykładowo, w testach poprawności, wymagających uruchomienia programu studenta, trzeba
sprecyzować, od której klasy rozpoczyna się wykonanie programu, a zatem taka klasa winna
znaleźć się w strukturze rozwiązania.
W SDKP występują dwa rodzaje definicji zadań: systemowe i nauczycieli. Przygotowany w ramach realizacji projektu zestaw definicji systemowych obejmuje ok. 100 zadań, które są gotowe
do wykorzystania w procesie dydaktycznym. Dodatkowo, każdy z nauczycieli może łatwo tworzyć własne definicje, dostosowane do jego potrzeb dydaktycznych. Definicje zadań zapisywaEduAkcja. Magazyn edukacji elektronicznej, nr 2 (12)/2016 , str. 106
ne są w języku YAML (Portal języka YAML, b.d.), który – jako nadzbiór notacji JSON – jest
od dawna utrwalonym standardem, chętnie używanym przez profesjonalnych developerów ze
względu na jego obrazowość, prostotę i zarazem zwięzłość.
Wybrane elementy postaci definicji zadania w formacie YAML przedstawia Listing 1.
Listing 1. Wybrane elementy schematu definicji zadania
Przykładowo, dla zadania, które na podstawie informacji, podanej jako argumenty wywołania programu, ma wykonać jakieś obliczenia i wypisać na konsoli ich wynik w postaci ciągu
liczb oraz ich sumy, definicja zadania może wyglądać tak jak na Listingu 2.
Listing 2. Przykładowa definicja testu wykonania
Występują tu dwa przypadki testowe zdefiniowane w sekcji data dla testu wykonania (RunTest): dla podanych argumentów A wynikiem ma być ciąg liczb 1, 2, 3, 6, a dla argumentów B
– ciąg liczb 11, 12, 13, 36. Testowanie odbywa się za pomocą wyrażenia regularnego, podanego
w outEquals, które określa, co ma stanowić wynik programu (podane liczby rozdzielone dowolną liczbą białych znaków, ewentualnie poprzedzone i zakończone białymi znakami). Etykiety
caseMsg podają zmniejszenie punktacji w przypadku wystąpienia błędu oraz jego opis. Przy
definiowaniu testu oprócz outEquals dostępne są też opcje outContains i outNotContains, z następującymi po nich listami wyrażeń regularnych, sprawdzające czy wyjście programu zawiera
(nie zawiera) tekstów, pasujących do wyrażeń regularnych z listy.
Jest to przykład zastosowania bardzo prostych środków testowania (regularnych wyrażeń).
Innym prostym narzędziem testowania poprawności wykonania programów są predefiniowane
reguły (inaczej zwane transformacjami) – zob. Listing 3.
Listing 3. Przykład zastosowania predefiniowanych transformacji
Na Listingu 3 jako exp podano oczekiwany wynik. Dla każdego przypadku testowego faktyczny i oczekiwany wynik podlega transformacji podanej pod kluczem transform: definicji testu.
Tu transformacja o nazwie alljoinspaces, polega na połączeniu wszystkich symboli (czyli ciągów
znaków nie zawierających białych znaków) za pomocą spacji. Niezależnie więc od tego ilu odstępów (spacji, znaków nowego wiersza itp.) użył student przy wypisywaniu wyniku, porównywane będą zestawy liczb rozdzielone jedną spacją. Jeśli tak przetworzone wyjście programu nie
będzie takie samo jak (w ten sam sposób przetworzony) oczekiwany wynik, zgłoszony zostanie
błąd opisany w caseMsg. W systemie zdefiniowano kilkanaście predefiniowanych transformacji
dla testów wykonania.
Takie proste środki weryfikacji (wyrażenia regularne i transformacje) często jednak nie są
wystarczające. Ograniczenie się do nich oznaczałoby nadmierne zawężenie rodzajów zadań
poddawanych testowaniu (nie wszystko daje się sprawdzić regularnymi wyrażeniami). Również
z punktu widzenia oceny pracy studenta i informowania go o rodzaju błędów, które popełnił,
są to narzędzia niewystarczające. W szczególności, w przykładzie z wypisywaniem liczb student
może wykonać zadanie częściowo poprawnie (np. nie dostosować się do wymaganego formatu
wyjścia, ale podać prawidłowe liczby). Weryfikacje z Listingu 2 nie uwzględniają tego – student
uzyska 0 punktów i żadnej informacji o tym, co naprawdę było złego w jego rozwiązaniu. Dlatego ważną rolę w SDKP odgrywają skrypty testujące.
3. Skrypty w SDKP – założenia i motywacje
Skrypty w SDKP – to niewielkie programy, które mogą:
• uzyskiwać i przetwarzać wyniki programów studentów, w szczególności porównywać je
z oczekiwanymi wynikami,
• dynamicznie uruchamiać programy studentów, wywoływać różne metody z klas tych programów, analizować dostępność i charakterystyki różnych elementów programów (klas, metod,
pól),
• działać na kodach źródłowych programów lub ich drzewach składniowych (AST) w celu analizy i oceny jakości oraz stylu rozwiązania.
W wielu zadaniach systemowych (gotowych do wykorzystania) zdefiniowano odpowiednie skrypty. Ale również dydaktycy, tworząc własne definicje zadań, mogą dostarczać dla nich
skryptów testujących.
Skrypty zapisywane są w języku Groovy, którego składnia i semantyka zawiera elementy
znacząco ułatwiające programowanie (Platforma Groovy, b.d.). Język Groovy pozwala również
na bezpośrednie stosowanie składni języka Java, co oznacza, że nauczyciel może „z miejsca”
programować skrypty testujące, ewentualnie stopniowo, w miarę poznawania języka Groovy,
wprowadzając w nich upraszczające program elementy składniowe. W tym kontekście należy
podkreślić, że decyzja projektowa, polegająca na wprowadzeniu otwartych dla nauczycieli bogatych środków testowania skryptowego, powinna realnie podnosić jakość automatycznej oceny.
Faktycznie, przecież każdy nauczyciel musi świetnie znać język programowania Java, zatem pisanie skryptów nie sprawi kłopotu i umożliwi istotne poszerzenie zakresu zadań poddawanych
automatycznej ocenie oraz wzbogacenie informacji o błędach popełnianych przez studentów.
Skrypty mogą być stosowane praktycznie we wszystkich modułach systemu, w ocenie wszystkich aspektów rozwiązań zadań programistycznych. Zanim – w drugiej części artykułu – przyjrzymy się przykładom, dotyczącym definiowania i wykonywania skryptów w różnych modułach systemu, warto rozważyć prosty przypadek użyteczności skryptów.
Przykładowe zadanie, podobne do tego z poprzedniego punktu, polega na wykonaniu skomplikowanych obliczeń na podstawie jakichś danych wejściowych (np. przekazanych jako argumenty programu). W wyniku obliczeń ma być wyprowadzony ciąg liczb oraz ich suma.
Co może zrobić student:
1. Uzyskać ciąg niewłaściwych liczb i źle policzyć ich sumę.
2. Uzyskać ciąg niewłaściwych liczb, ale dobrze policzyć ich sumę.
3. Uzyskać ciąg niewłaściwych liczb lub nie wypisać ciągu liczb, ale podać sumę właściwych
liczb (np. wyliczoną inną metodą niż proste sumowanie uzyskanych liczb).
4. Uzyskać ciąg właściwych liczb, ale podać złą ich sumę.
5. Wyprowadzać liczby w dowolnej (innej od oczekiwanej) kolejności.
6. Podać sumę na początku lub na końcu ciągu wyprowadzonych liczb.
7. Wyprowadzać liczby i sumę jako wartości całkowite lub rzeczywiste, a w tym ostatnim
przypadku stosować jako separator miejsc dziesiętnych kropkę lub przecinek albo nawet
notację naukową.
8. Oprócz liczb wyprowadzić jakąś tekstową informację, np. 1+2=3.
Obniżać punktację chcemy tylko w przypadkach 1–4, przy czym w zróżnicowany w zależności od popełnionego błędu sposób. Oczywiście, ani regularne wyrażenia ani proste transformacje nie znajdą tu zastosowania. Na pomoc przychodzą skrypty, które możemy zapisywać pod
kluczem script w definicji testu (zob. Listing 5).
Listing 5. Umiejscowienie kodu skryptu w definicji zadania
System uruchamia program studenta, a po jego zakończeniu kod skryptu, który w zmiennej
out uzyskuje wyniki programu, w zmiennej exp – oczekiwane wyjście, a w zmiennej caseMsg
listę: [ obniżenie punktacji, ogólny opis błędu] spod klucza caseMsg definicji testu. Skrypt zwraca listę opisów wykrytych błędów w formacie : [ [zmniejszpunkt1, opis1], [zmniejszpunkt1,
opis2] ]. Błędy te są zapisywane w bazie danych wyników testów. Kod skryptu dla omawianego
zadania przedstawia Listing 6.
Listing 6. Przykładowy skrypt elastycznego testowania wyniku programu
Komentarze w kodzie skryptu wyjaśniają znaczenie poszczególnych instrukcji. Skrypt korzysta z dobrodziejstw składni języka Groovy, ale dydaktycy nieznający tej platformy mogą to samo
napisać w języku Java.
Warto podkreślić, że dzięki zastosowaniu skryptów, w których szczegółowo i elastycznie można analizować wyniki programów, uzyskujemy kilka pozytywnych efektów:
• specyfikacje zadań do wykonania nie muszą być bardzo rygorystyczne, silnie ograniczające
sposoby rozwiązania i prezentacji wyników; w omawianym przykładzie treść zadania może
być bardzo ogólna, nie stawiająca konkretnych wymagań, co do sposobu prezentacji wyniku,
np. „wypisz na konsoli liczby pierwsze, zawarte pomiędzy dwoma liczbami, podanymi jako
argumenty programu. Wypisz też sumę wynikowych liczb”.
• nawet gdy specyfikacja wymaga określonej prezentacji wyników, to studenci, którzy uzyskali
dobry wynik, ale popełnili błędy w formatowaniu wyjścia, nie będą czuli się pokrzywdzeni (przy
testowaniu wyniku za pomocą wyrażeń regularnych uzyskaliby 0 punktów, użycie skryptu pozwala na przyznanie im pozytywnej oceny za dobry wynik, być może nieco tylko pomniejszonej
z uwagi na niespełnienie wymagań co do formatowania). Dla przykładu, skrypt z Listingu 5 pozwala właściwie ocenić rozwiązanie niezależnie od formatu i kolejności wyprowadzanych liczb,
a także w sytuacji, gdy student uznał za stosowne dodać do wypisywanych liczb jakieś napisy,
• można przyznawać punkty nawet za drobne pozytywne elementy rozwiązania; w omawianym
przykładzie studenci, którzy nie uzyskali właściwych wyników, ale przynajmniej dobrze zsumowali (wadliwe) liczby, uzyskają 2 punkty na możliwych 10; takie podejście pozwala uhonorować starania i pracę studenta (uzyskuje symboliczną pozytywną ocenę, a nie 0 punktów
tak jak osoby, które w ogóle nic nie zrobiły),
• studenci uzyskują więcej informacji o tym, jakie konkretnie błędy popełnili, a nie tylko zdawkowy komunikat o tym, że wynik jest zły.
Oczywiście, wyniki testów (nie tylko tych wykonywanych z użyciem skryptów) są prezentowane studentom i nauczycielom w odpowiedniej, zrozumiałej formie (zob. Rys. 1).
Rysunek 1. Przykładowa prezentacja wyników testów
Więcej informacji na temat możliwości użycia skryptów w SDKP znajdzie Czytelnik w drugiej części artykułu.
4. Bibliografia
1. Ala-Mutka, K., Uimonen, T., Jarvinen, H. M. (2004). Supporting students in C++ programming courses
with automatic program style assessment. Journal of Information Technology Education, 3.
2. Barteczko, K. (2012). Plagiaty rozwiązań zadań programistycznych w zdalnym nauczaniu. Magazyn Edukacji Elektronicznej EduAkcja, 2(4).
3. Barteczko, K. (2013). Założenia Systemu Doskonalenia Kwalifikacji Programistycznych w ramach zdalnego
nauczania. W: L. Banachowski (Red.), Postępy e-edukacji. Warszawa: Wydawnictwo PJWSTK.
4. Barteczko, K. (2015). Weryfikacja stylu programowania w rozwiązaniach zadań programistycznych. Magazyn Edukacji Elektronicznej EduAkcja, 2(10).
5. Caiza, J. C., Del Alamo, J. M. (2013). Programming assignments automatic grading: Review of tools and
implementations. Inted 2013 Proceedings.
6. Douce, C., Livingstone, D., Orwell, J. (2005). Automatic test-based assessment of programming: A review.
ACM Journal of Educational Resources in Computing, 5(3).
7. Edwards, S. H., Perez-Quinones, M. A. (2008). Web-CAT: Automatically Grading Programming Assignments. ACM SIGCSE Bulletin, 40.
8. Forsythe, G. E., Wirth, N. (1965). Automatic Grading Programs. Communications ACM, 8.
9. Gupta, S., Dubey, K. S. (2012). Automatic assessment of programming assignment. Computer Science &
Engineering: An International Journal (CSEIJ), 2(1).
10. Higgins, C., Gray, G., Symeonidis, P., Tsintsifas, A. (2005). Automated assessment and experiences of teaching programming. ACM Journal on Educational Resources in Computing, 5(3).
11. Ihantola, P., Ahoniemi, T., Karavirta, V., Seppälä, O. (2010). Review of recent systems for automatic assessment of programming assignments. Proceedings of the 10th Koli Calling International Conference on
Computing Education Research. ACM: New York, USA.
12. Java Reflection API (b.d.). Pobrano z: https://docs.oracle.com/javase/tutorial/reflect, dokumentacja pakietu
java.lang.reflect
13. Joy, M. S., Griffiths, N., Boyatt, R. C. (2005). The BOSS Online Submission and Assessment System. ACM
Journal on Educational Resources in Computing, 5(3).
14. Ljana, L., Martin, M., Pareja-Flores, F. (2012). FLOP, a free laboratory of programming. Proceedings of the
12th Koli Calling International Conference on Computing Education Research.
15. Queirós, R. A. P., Leal, J. P. (2012). PETCHA: A Programming Exercises Teaching Assistant. Proceedings of
the 17th ACM Annual Conference on Innovation and Technology in Computer Science Education.
16. Sherman, M., Bassil, S., Lipman, D., Tuck, N., Martin, F. (2013). Impact of Auto-Grading on an Introductory
Computing Course. Journal of Computing Sciences in Colleges, 28(6).
17. Rodríguez-del-Pino, J. C., Rubio-Royo E., Hernández-Figueroa, Z. (2012). A Virtual Programming Lab
for Moodle with automatic assessment and anti-plagiarism features. Proceedings of the 2012 International
Conference on e-Learning, e-Business, Enterprise Information Systems, & e-Government.
18. Striewe, M., Goedicke, M., Balz, M. (2008). Computer Aided Assessments and Programming Exercises with
JACK. Technical Report 28, ICB, University of Duisburg-Essen.
19. Tiantian, W., Xiaohong, S., Peijun, M., Yuying, W., Kuanquan, W. (2009). Autolep: An automated learning
and examination system for programming and its application in programming course. Education Technology and Computer Science, 1.
20. Platforma Groovy (b.d.). Pobrano z: http://groovy-lang.org
21. Portal języka YAML (b.d.). Pobrano z: http://yaml.org
Scripts in Automatic Assessment of Programming
Assignments. Part I. Background and Motivations
Summary
Keywords: teaching programming, automatic assessment of programming assignments, static code analysis, dynamic code analysis, software testing, scripts, Java, Groovy, metaprogramming, AST, reflection
In the Programming Skills Development System (PSDS), created and implemented in the Polish-Japanese Academy of Information Technology, teachers can define scripts for automatic assessment of programming exercises.
Advanced tools for static and dynamic code analysis are available for scripts definition. Writing any script is easy
for teachers of programming languages, yet using it in process of automatic assessment could improve the quality
of solutions analysis. The first part of the article contains short information about PSDS and some background and
main motivations for introducing scripts in the system.

tutaj - EduAkcja. Magazyn Edukacji Elektronicznej

Transkrypt

Podobne dokumenty

PDF: Automatyzacja w procesie testowania oprogramowania

mapy cyfrowe dla biznesu

tutaj - EduAkcja. Magazyn Edukacji Elektronicznej

Warsztaty: Testowanie oprogramowania - program

Szkolenie "Testowanie automatyczne" - oferta

STANDARDY DLA OSÓB STOSUJĄCYCH TESTY W BIZNESIE

czytaj więcej

Marta Jung Proces testowania i jego wpływ na jakość produktu w