III-1
BAB III
ANALISIS
Kegiatan pengajaran pemrograman pada Program Studi Sarjana Teknik Informatika ITB (S1-IF-ITB) sejak tahun 2006 diikuti oleh mahasiswa dalam jumlah besar, sehingga timbul kebutuhan akan sebuah alat bantu pengajaran untuk menilai source code mahasiswa. Dalam Tugas Akhir ini, akan dibangun sebuah perangkat lunak autograder untuk memenuhi kebutuhan S1-IF-ITB. Pembangunan autograder akan dilakukan dengan menggunakan acuan perangkat lunak autograder yang sudah ada, sebagaimana telah dibahas pada Subbab 2.1.3. Autograder ini akan memiliki karakteristik khusus, yaitu dirancang untuk mampu menangani berbagai bahasa pemrograman yang digunakan dalam kegiatan pengajaran S1-IF-ITB, pada Tugas Akhir ini yang diimplementasikan yaitu Lisp dan Pascal. Perangkat lunak autograder yang sudah ada saat ini umumnya hanya menangani bahasa pemrograman C++ dan Java saja. Autograder yang akan dibangun pada Tugas Akhir ini diberi nama Phobos.
Dalam bab Analisis ini, akan diberikan penjelasan mengenai konteks pengembangan, analisis proses penilaian, dan spesifikasi kebutuhan untuk autograder yang akan dibangun. Konteks pengembangan untuk autograder Phobos pada Subbab 3.1 akan memberikan deskripsi singkat mengenai Learning Management Systemmilestone dan autograderPhobos sebagai sebuah sistem mandiri. Pembahasan mengenai proses penilaian pada Subbab 3.2 akan memberikan latar belakang perancangan proses penilaian otomatis, dan besaran-besaran penilaian yang akan diterapkan dalam Phobos. Di dalam Subbab 3.3 akan didefinisikan secara formal kebutuhan perangkat lunak untuk Phobos.
3.1 Deskripsi
Sistem
Dalam pengajaran pemrograman pada S1-IF-ITB, terdapat beberapa bentuk kegiatan dengan hasil berupa program, antara lain praktikum, tugas besar dan ujian praktek. Dalam praktikum, mahasiswa berlatih membuat program dengan topik tertentu di laboratorium. Praktikum umumnya dilaksanakan tiap minggu, dengan batas akhir pengumpulan deliverable berupa source code program bervariasi antara pada akhir waktu praktikum (untuk ujian praktikum dan topik praktikum yang mudah) atau setelah praktikum (untuk topik yang lebih rumit). Tugas besar pada umumnya dilakukan secara berkelompok, dengan jangka waktu pengerjaan berkisar 2-3 minggu, dengan deliverable berupa source code program dan dokumentasinya. Ujian praktek menguji kemampuan siswa untuk membuat program secara individual dalam laboratorium.
Berbagai kegiatan yang berlangsung dalam pengajaran pemrograman pada S1-IF-ITB ini akan ditangani oleh suatu Learning Management System (LMS). Learning Management System adalah sekumpulan perangkat lunak dan proses yang saling terhubung, berbagi data dan berkontribusi dalam manajemen pengalaman pembelajar dalam sebuah institusi [JIS06]. LMS yang dibangun untuk menangani berbagai kegiatan pengajaran pemrograman pada S1-IF-ITB bernama milestone. Saat ini, milestone telah digunakan untuk pengumpulan dan manajemen tugas pemrograman. Representasi Learning Management System milestone sebagai sebuah use case sistem dapat dilihat pada Gambar III-1.
System
Instruktur Mahasiswa
Meng-upload tugas pemrograman
Berkomunikasi
Memberi tugas
Melakukan penilaian
Mendeteksi plagiarisme
Gambar III-1 Diagram Use-Case Sistem milestone
Fungsi penilaian pada LMS milestone akan ditangani secara khusus oleh sebuah sistem autograder terpisah. Tugas Akhir ini akan membahas mengenai pengembangan sebuah sistem penilaian source code otomatis baru yang dinamai Phobos. LMS milestone tidak akan dibahas lebih lanjut, karena hanya melakukan proses pengumpulan source code tugas pemrograman saja dan tidak menangani permasalahan penilaian.
Autograder Phobos bertugas melakukan penilaian otomatis terhadap sekumpulan source code yang berasal dari hasil tugas pemrograman yang telah diserahkan oleh mahasiswa. Dengan kata lain, Phobos merupakan alat bantu yang dapat digunakan oleh instruktur untuk menilai tugas pemrograman siswa dalam jumlah besar secara otomatis. Meskipun Phobos direncanakan sebagai salah satu komponen dari LMS milestone, dalam Tugas Akhir ini Phobos dirancang agar dapat juga digunakan dan diuji sebagai suatu sistem mandiri.
Pembangunan autograderPhobos didasari oleh kebutuhan proses pengajaran pemrograman dalam S1-IF-ITB yang belum dipenuhi oleh aplikasi autograder yang sudah ada. Beberapa aplikasi autograder yang telah dibuat, seperti CourseMaster atau GAME, memiliki sifat generik, yaitu mampu menangani source code dalam berbagai bahasa pemrograman. Dari berbagai aplikasi autograder generik yang telah dieksporasi, bahasa yang ditangani umumnya adalah C++ dan Java. Belum ada autograder generik yang mencakup bahasa pemrograman dasar yang digunakan pada S1-IF-ITB, Lisp dan Pascal. Pada Tugas Akhir ini, Phobos dibangun untuk melakukan penilaian source code dalam bahasa pemrograman Lisp, Pascal, namun dirancang agar dapat dikembangkan lebih lanjut untuk menangani bahasa C, C++ dan Java.
Autograder Phobos akan melakukan penilaian otomatis dengan masukan berupa skema penilaian dan source code yang akan dinilai dari instruktur. Phobos akan menyimpan skema penilaian dan data uji dalam bentuk file XML, source code yang dinilai dalam bentuk arsip terkompresi, sementara hasil proses penilaian disimpan dalam basis data. Hasil penilaian kemudian dapat ditampilkan dalam bentuk laporan nilai kolektif, yang dapat di-drill down menjadi laporan nilai individu.
Source code yang hendak dinilai dapat berasal dari tugas besar, praktikum, ujian praktek, atau dari kegiatan lainnya, misalnya latihan mandiri atau pelatihan lomba pemrograman. Secara umum, dalam pembahasan Tugas Akhir ini, setiap kegiatan dengan hasil berupa source code yang hendak dinilai disebut sebagai penugasan (assignment). Hasil source code yang diserahkan oleh mahasiswa untuk penugasan tertentu disebut sebagai serahan tugas atau tugas yang diserahkan (submitted assignment).
Definisi skema penilaian (marking scheme definition) adalah daftar jenis penilaian yang
dilakukan terhadap tugas dan bobot relatif masing-masing penilaian terhadap nilai keseluruhan. Secara tidak langsung, definisi skema penilaian juga sekaligus bertindak sebagai skenario penilaian yang dilakukan terhadap source code. Jika penilaian yang hendak dilakukan hanya terdiri dari penilaian eksekusi, maka dalam skema penilaian hanya dicantumkan jenis penilaian eksekusi saja. Jika penilaian yang hendak dilakukan hanya berupa penilaian whitebox, maka dalam definisi skema penilaian hanya dicantumkan penilaian jenis whitebox saja. Definisi skema penilaian juga dapat memuat kombinasi dari berbagai jenis penilaian yang hendak dijalankan. Definisi skema penilaian harus dibuat secara terpisah untuk setiap penugasan yang hasilnya yang hendak dinilai.
Jika hendak dilakukan penilaian eksekusi, maka skema penilaian harus memuat data uji. Data uji (test data) adalah sekumpulan butir uji yang akan digunakan untuk uji eksekusi. Butir uji
(test item) adalah pasangan data masukan untuk program yang diuji beserta data keluaran yang diharapkan dari program untuk masukan tersebut. Data uji harus mengandung cukup banyak butir uji agar dapat memilih butir uji secara acak. Skenario uji (test scenario) adalah butir uji yang telah dipilih secara acak oleh autograder untuk penilaian eksekusi pada serahan tugas tertentu.
Laporan nilai yang dihasilkan oleh autograderPhobos ada dua macam, yaitu laporan nilai kolektif dan laporan nilai individu. Laporan nilai kolektif adalah daftar nilai akhir sekumpulan serahan tugas untuk penugasan tertentu. Laporan nilai individu adalah kombinasi dari nilai kuantitatif hasil pengukuran besaran-besaran penilaian untuk satu serahan tugas, beserta dengan penjelasan tekstual singkat mengenai nilai yang dihasilkan (khususnya jika pengukuran besaran penilaian menghasilkan nilai di luar batas normal).
Pada bagian berikutnya, akan dianalisis lebih mendalam mengenai proses penilaian yang dilakukan, masukan yang dibutuhkan dan keluaran dari sistem autograder Phobos. Detil lebih lanjut mengenai definisi skema penilaian, data uji dan laporan nilai akan diberikan pada bab perancangan.
3.2 Penilaian Program Otomatis
Sebuah sistem penilai source code otomatis harus dirancang dengan cermat, karena berhubungan langsung dengan proses belajar mahasiswa. Dalam Tugas Akhir ini, sistem autograder dirancang untuk mengikuti proses penilaian yang dilakukan oleh manusia. Sebagaimana telah dibahas pada Subbab 2.1.2, proses penilaian tugas pemrograman secara otomatis menggunakan sistem komputer dapat mengikuti proses penilaian tugas manual sampai dengan level tertentu.
Analisis proses penilaian tugas otomatis yang didasarkan pada proses penilaian manual akan dibahas pada Subbab 3.2.1. Otomasi proses pengujian program otomatis akan dibahas secara khusus dalam Subbab 3.2.2.
3.2.1 Proses Penilaian Source Code Manual
Sebagaimana telah dibahas pada Subbab 2.1.2, penilaian tugas source code merupakan sekumpulan proses yang bertujuan melakukan evaluasi terhadap masukan berupa source code, yang hasilnya dinyatakan secara kuantitatif dalam bentuk nilai akhir.
Setelah tugas berupa source code diserahkan oleh siswa, dapat dilakukan penilaian blackbox maupun whitebox. Dalam penilaian blackbox, source code dikompilasi untuk menghasilkan sebuah program executable yang dapat dijalankan oleh penilai. Penilai kemudian melakukan penilai terhadap program dengan cara memberikan masukan kepada program dan mengevaluasi hasil keluarannya. Dalam penilaian whitebox, penilai akan melakukan analisis terhadap source code untuk menilai aspek intrinsik kode seperti kompleksitas dan keterbacaan program. Nilai hasil eksekusi program dan/atau nilai source code akan kemudian menjadi masukan untuk proses perhitungan nilai akhir, yang kemudian akan dapat dikembalikan kepada siswa.
Pada proses penilaian manual, definisi proses penilaian dan pengujian dapat bersifat intrinsik dalam individu penilai. Skema penilaian atau definisi proses pengujian tidak mutlak harus ditentukan secara konkrit terlebih dahulu. Penilai manusia dapat memberikan nilai dengan mempertimbangkan berbagai aspek sekaligus, termasuk semantik program. Penilai manusia juga dapat menguji program secara langsung pada saat eksekusi dengan memberikan masukan secara impromptu lalu mengevaluasi keluaran yang dihasilkan oleh program.
Dalam penilaian manual, penilai dapat memberikan evaluasi terhadap hasil pengerjaan tugas dalam bentuk komentar atau pembahasan solusi kepada siswa secara langsung seperti melalui diskusi dengan siswa, maupun secara tidak langsung ketika siswa bertanya kepada penilai. Sebagaimana telah dibahas pada bab 2.1.1, nilai dan penjelasan ini merupakan umpan balik yang amat berguna terhadap proses pembelajaran siswa.
Kelebihan proses penilaian manual yaitu bahwa proses penilaian dapat bersifat fleksibel, dengan proses penilaian yang bervariasi sesuai dengan konteks pemberian tugas dan skala tugas. Konteks pemberian tugas yang diperhitungkan dalam proses penilaian umumnya menyangkut aspek konseptual tugas dan bahasa pemrograman yang digunakan. Aspek konseptual tugas adalah keterkaitan antara tugas dengan konsep tertentu yang harus dikuasai oleh siswa. Sebagai ilustrasi, tugas praktikum bertopik stack membutuhkan penilaian khusus untuk implementasi primitif yang terkait pada konsep stack, seperti push atau pop. Bahasa pemrograman yang digunakan untuk tugas tertentu juga dapat mempengaruhi proses
penilaian. Sebagai ilustrasi, tugas praktikum yang menggunakan bahasa C dan C++ harus membutuhkan penilaian khusus untuk manajemen memori (karena bahasa-bahasa ini tidak menyediakan manajemen memori otomatis). Penilaian manual dapat ikut mempertimbangkan konteks tugas karena penilai manusia dapat memahami konteks pemberian tugas dengan mudah. Skema penilaian yang digunakan oleh penilai manual dapat berubah-ubah secara fleksibel dari satu tugas ke tugas yang lain, bergantung pada topik dan skala tugas.
Proses penilaian manual memiliki kelemahan yaitu menghabiskan banyak sumber daya karena diperlukan waktu, pemikiran dan tenaga penilai untuk melakukan evaluasi terhadap hasil kerja siswa. Selain itu, penilai manusia juga cenderung bersifat subjektif terhadap individu penilai maupun terhadap tugas yang dinilai, terlebih lagi jika skema penilaian dan proses pengujian tidak didefinisikan secara konkrit.
3.2.2 Proses Penilaian Source Code Otomatis
Pada Subbab ini akan dibahas mengenai proses penilaian tugas pemrograman otomatis dengan keterbatasannya, variasi proses penilaian otomatis, serta batasan dan karakteristik pada masing-masing varian.
Pada proses penilaian otomatis, sistem komputer yang disebut autograder menggantikan penilai untuk melakukan kompilasi, uji eksekusi program, analisis source code, dan perhitungan nilai. Penilaian eksekusi program siswa secara otomatis dilakukan dengan cara menyediakan masukan yang akan diberikan kepada program siswa, dan kemudian mencocokkan keluaran yang dihasilkan oleh program siswa dengan keluaran yang diharapkan. Penilaian source code dilakukan dengan cara mengukur besaran-besaran penilaian source code yang telah dibahas pada Subbab 2.2.2 dan mengubahnya ke dalam nilai. Dengan penilaian eksekusi program dan penilaian source code (yang merupakan proses yang paling memakan sumber daya) dilakukan secara otomatis, proses penilaian dapat dilakukan dengan cepat tanpa menghabiskan banyak waktu dan tenaga penilai manusia. Hal ini merupakan kelebihan dari proses penilaian otomatis.
Sebuah autograder dapat menghasilkan nilai kuantitatif dari source code tugas siswa. Penilai otomatis dapat memberikan penjelasan berupa laporan hasil penilaian secara mendetil dan pesan untuk kesalahan yang timbul, namun tidak dapat memberikan evaluasi berupa komentar atau pembahasan sebagaimana pada proses penilaian manual. Hal ini merupakan kelemahan dari proses penilaian otomatis.
Sebuah autograder membutuhkan definisi konkrit langkah-langkah penilaian (termasuk pengujian program siswa) agar dapat menjalankan penilaian secara otomatis, baik dengan cara meletakkannya dalam program / hardcoded, ataupun sebagai masukan autograder. Proses penilaian yang dilakukan terhadap setiap source code menjadi seragam. Di satu sisi, hal ini menjadi kelebihan proses penilaian otomatis karena penilaian oleh autograder bersifat objektif. Di sisi lain, hal ini menyebabkan proses penilaian oleh autograder tidak akan memiliki fleksibilitas dalam menilai tugas sesuai dengan konteks dan skala program sejauh penilaian manual.
Implementasi proses penilaian otomatis menggunakan autograder yang definisi langkah penilaian dan pengujiannya terkandung dalam instruksi program / hardcoded adalah implementasi yang paling tidak fleksibel, karena perubahan proses penilaian akan mengakibatkan pengodean ulang pada autograder. Proses penilaian otomatis dapat dibuat lebih fleksibel dengan menjadikan merancang autograder sebagai sebuah alat bantu berisi sekumpulan fungsi penilaian yang dapat dijalankan oleh penilai. Autograder kemudian dirancang untuk menerima definisi skema penilaian, yang berisi daftar penilaian yang akan dijalankan. Dengan demikian, proses penilaian untuk setiap penugasan dapat dibuat berbeda-beda satu sama lain. Hal ini disebabkan karena secara tidak langsung, jenis-jenis penilaian yang tercantum pada definisi skema penilaian akan menjadi langkah-langkah proses penilaian yang dijalankan oleh autograder.
Meskipun autograder dirancang dengan masukan berupa definisi skema penilaian, kemampuannya untuk melakukan penilaian yang berkorelasi dengan konteks tugas (aspek konseptual dan bahasa pemrograman) masih tetap terbatas. Aspek konseptual tugas bersifat spesifik terhadap masing-masing tugas. Penilaian terhadap aspek konseptual membutuhkan pemahaman terhadap semantik program, yang sebagaimana telah dibahas pada Subbab 2.2.1.1 belum dimiliki oleh autograder manapun. Penilaian kontekstual yang spesifik terhadap bahasa pemrograman tertentu akan mengakibatkan autograder terikat pada bahasa pemrograman tersebut, dan hal ini bukan merupakan karakteristik yang diharapkan. Alternatif implementasi di mana skema penilaian dijadikan sebagai masukan autograder inilah yang akan dibahas lebih lanjut dalam Tugas Akhir ini.
Ikhtisar mengenai perbandingan fitur-fitur pada proses penilaian manual dan otomatis dapat dilihat pada Tabel III-1. Pada ikhtisar tersebut juga diberikan ringkasan fitur-fitur penilaian otomatis yang dimiliki oleh ketiga aplikasi autograder yang dibahas pada Subbab 2.1.3 dibandingkan dengan Phobos.
Tabel III-1 Perbandingan fitur proses penilaian manual, autograder yang sudah ada & Phobos Autograder
Fitur Penilaian Penilaian
Manual ASSYST [JAC97] CourseMaster [ZIN91] GAME [BLU04] Phobos
Skema penilaian fleksibel Ya Bobot saja Bobot &
Proses Bobot saja
Bobot & Proses Detil nilai Ya,
Subjektif Tidak Ya Tidak Ya
Pesan kesalahan Ya Ya Umpan balik kepada siswa Penjelasan Ya,
Subjektif Tidak Terbatas Tidak Terbatas Sumber data uji Penilai
Penilai & submisi
siswa
Penilai Penilai Penilai
Konsep tugas Tidak
Penilaian konteks program Bahasa pemrograman Ya Ada C++, Java C, C++,
Java Lisp, Pascal
Semantik program Ya Tidak
3.3 Spesifikasi
Autograder Phobos
Berdasarkan analisis penilaian tugas otomatis yang telah dijelaskan pada Subbab 3.2, maka dibuat spesifikasi untuk sebuah perangkat lunak source code autograder yang dinamai Phobos. Pada Subbab ini diberikan model use case dan skenario penggunaan, spesifikasi fungsional dan non fungsional beserta deskripsi arsitektural dan dekomposisi subsistem-subsistem dalam autograderPhobos.
3.3.1 Model Use Case untuk Phobos
Berdasarkan analisis proses penilaian otomatis pada Subbab 3.2.2, maka dapat dibuat model use case untuk Phobos. Diagram use case untuk Phobos akan dibahas pada Subbab 3.3.1.1, sementara skenario use casePhobos akan dibahas pada Subbab 3.3.1.2.
3.3.1.1 Diagram Use Case Phobos
Berdasarkan kebutuhan fungsional yang telah ditentukan, maka use case yang dimiliki oleh Phobos ada 4, yaitu membuat skema penilaian, menilai tugas source code secara otomatis, melihat laporan nilai, dan menghapus hasil penilaian. Diagram use case untuk Phobos dapat dilihat pada Gambar III-2.
System
Instruktur
Menghapus Hasil Penilaian Membuat definisi skema penilaian
Melihat Laporan Nilai
Menilai Tugas Source Code secara Otomatis
Menilai eksekusi program
Menilai SLOC program
Menilai kompleksitas siklomatik
Menilai proporsi komentar
Menilai identitas file
Menilai nama identifier
Menilai indentasi kode
Menilai efisiensi program
<<extend>> <<extend>> <<extend>> <<extend>> <<extend>> <<extend>> <<extend>> <<extend>>
Gambar III-2 Diagram Use Case Phobos
Phobos dirancang sebagai alat bantu pengajaran pemrograman, sehingga aktor yang dilibatkan dalam use case ini adalah instruktur. Di masa depan, Phobos dapat juga dikembangkan dalam skenario interaktif yang melibatkan siswa. Kemungkinan skenario interaktif ini tidak akan dibahas lebih lanjut dalam Tugas Akhir ini. Keterangan selengkapnya mengenai aktor dalam diagram tersebut dapat dilihat pada Tabel III-2.
Tabel III-2 Definisi Aktor dalam Diagram Use Case Phobos
Karena instruktur dapat memilih penilaian apa saja yang akan dilakukan oleh autograder, maka use case menilai tugas source code (PHB-UC-02) dapat mencakup berbagai use-case untuk penilaian yang dapat dilakukan oleh Phobos. Proses pemilihan jenis-jenis penilaian yang berkorespondensi dengan masing-masing use case akan dibahas pada Subbab 3.3.2. Keterangan selengkapnya mengenai seluruh use case dalam diagram tersebut dapat dilihat pada Tabel III-3.
Aktor Keterangan
Instruktur Pengguna Phobos yang bertanggung jawab untuk menyediakan definisi skema penilaian, memulai penilaian otomatis dan memberikan source code. Instruktur juga dapat melihat hasil penilaian. Dalam praktek, peran aktor dapat dilaksanakan oleh dosen atau asisten.
Tabel III-3 Definisi Use-Case untuk Phobos
Nomor Use Case Deskripsi
PHB-UC-01 Membuat definisi skema penilaian
Membuat skema penilaian, yang berisi spesifikasi tugas (deskripsi tugas dan jenis-jenis penilaian) dan data uji yang akan digunakan dalam proses penilaian oleh sistem autograder
PHB-UC-02 Menilai source code Melakukan proses penilaian terhadap serahan tugas yang berupa source code. Proses penilaian dimulai dengan interpretasi source code dan eksekusi bersama data uji untuk menguji ketepatan program. Source code
kemudian dianalisis menurut besaran-besaran penilaian analitik. Hasil penilaian kemudian dikombinasikan menurut skema penilaian untuk menghasilkan nilai akhir dari source code.
PHB-UC-03 Melihat laporan nilai Melihat laporan nilai hasil proses penilaian oleh
autograder.
PHB-UC-04 Menghapus hasil penilaian Menghapus data hasil penilaian yang pernah dibuat oleh
autograder engine jika tidak lagi diperlukan. PHB-UC-05 Menilai eksekusi program Menilai program berdasarkan hasil eksekusi dengan
menggunakan data uji.
PHB-UC-06 Menilai SLOC program Menilai kompleksitas program berdasarkan jumlah baris kode (tanpa baris komentar) dari program .
PHB-UC-07 Menilai kompleksitas siklomatik
Menilai kompleksitas program berdasarkan jumlah alur percabangan eksekusi pada program.
PHB-UC-08 Menilai proporsi komentar Menilai keterbacaan kode berdasarkan jumlah baris komentar terhadap total baris source code dan rata-rata panjang baris komentar.
PHB-UC-09 Menilai keberadaan identitas pembuat source code
Menilai keterbacaan kode berdasarkan kepatuhan terhadap konvensi mengenai pemberian identitas untuk tiap file source code
PHB-UC-10 Menilai nama identifier Menilai keterbacaan kode berdasarkan rata-rata panjang nama identifier.
PHB-UC-11 Menilai indentasi kode Menilai keterbacaan kode berdasarkan ketepatan indentasi kode.
PHB-UC-12 Menilai efisiensi program Menilai efisiensi kode berdasarkan rata-rata jumlah eksekusi perintah source code program.
3.3.1.2 Skenario Penggunaan Phobos
Pada Subbab ini akan dijelaskan tentang skenario penggunaan Phobos untuk membuat skema penilaian, menilai submisi tugas, dan melihat laporan nilai. Skenario yang digambarkan pada bagian ini merupakan skenario normal. Skenario use case selengkapnya dapat dilihat pada LAMPIRAN D.
Skenario penggunaan autograder Phobos untuk membuat definisi skema penilaian dapat dilihat pada Gambar III-3. Pada skenario ini terdapat prekondisi bahwa aplikasi telah menampilkan form pembuatan skema penilaian baru kepada pengguna (instruktur). Berikut ini adalah penjelasan skenario tersebut :
1. Instruktur membuat definisi skema penilaian pada form aplikasi dan mengirimkannya kepada autograderPhobos melalui web browser.
2. Browser mengirimkan data definisi skema penilaian kepada autograderPhobos 3. AutograderPhobos menyimpan definisi skema penilaian pada persistent storage 4. Autograder Phobos mengirimkan pesan keberhasilan beserta definisi skema
penilaian yang telah disimpan.
5. Web browser menampilkan pesan dan definisi skema penilaian yang baru dari autograder.
Gambar III-3 Skenario penggunaan Phobos untuk membuat definisi skema penilaian
Skenario penggunaan autograder Phobos untuk menilai source code dapat dilihat pada Gambar III-4. Pada skenario ini terdapat prekondisi bahwa aplikasi telah menampilkan form berisi daftar source code dan definisi skema penilaian pada sistem kepada pengguna (instruktur). Berikut ini adalah penjelasan skenario tersebut :
1. Instruktur memberikan alamat tempat file arsip berisi serahan-serahan tugas berupa source code yang hendak dinilai serta definisi skema penilaian yang hendak digunakan kepada halaman aplikasi web Phobos.
2. Web browser meneruskan request tersebut menuju autograderPhobos.
3. Autograder Phobos memulai penilaian terhadap seluruh serahan tugas dalam satu praktikum, termasuk di dalamnya membangkitkan proses penilaian sesuai dengan definisi skema penilaian yang diminta hingga laporan nilai tersimpan pada persistent storage. Selama proses ini, koneksi antara browser dengan AutograderPhobos tetap dipertahankan.
4. AutograderPhobos mengirimkan status bahwa penilaian telah selesai dilakukan. 5. Web browser menampilkan pesan bahwa penilaian otomatis telah selesai dilakukan.
Gambar III-4 Skenario penggunaan Phobos untuk menilai source code
Skenario penggunaan autograder Phobos untuk melihat hasil penilaian dapat dilihat pada Gambar III-5. Pada skenario ini terdapat prakondisi bahwa aplikasi telah menampilkan semua laporan nilai yang tersedia pada sistem kepada pengguna (instruksi). Berikut ini adalah penjelasan skenario tersebut :
1. Instruktur memilih laporan nilai tugas yang hendak dilihat melalui web browser. 2. Web browser meneruskan permintaan laporan tersebut menuju autograderPhobos. 3. Autograder Phobos melakukan query pada persistent storage untuk mengambil isi
laporan dan mengatur format laporan nilai dalam bentuk HTML. 4. AutograderPhobos mengirimkan laporan nilai kepada pengguna. 5. Web browser menampilkan laporan nilai kepada pengguna.
Komputer yang terinstalasi Phobos Phobos Instruktur 4 5 Komputer user HTTP 2 1 3 Web Browser Persistent Storage
Skenario penggunaan autograderPhobos untuk menghapus data hasil penilaian dapat dilihat pada Gambar III-5. Pada skenario ini terdapat prakondisi bahwa aplikasi telah menampilkan semua proses penilaian yang telah dilakukan dan hasilnya tersedia pada sistem. Berikut ini adalah penjelasan skenario tersebut :
1. Instruktur memilih laporan nilai tugas yang hendak dihapus melalui web browser. 2. Web browser meneruskan permintaan laporan tersebut menuju autograderPhobos. 3. AutograderPhobos menghapus data hasil penilaian dari persistent storage. 4. AutograderPhobos mengirimkan laporan keberhasilan penghapusan data.
5. Web browser menampilkan laporan keberhasilan penghapusan data kepada pengguna.
Gambar III-6 Skenario penggunaan Phobos untuk menghapus hasil penilaian
3.3.2 Spesifikasi Fungsional Phobos
AutograderPhobos dirancang sebagai alat bantu dengan serangkaian kemampuan penilaian yang dapat dikombinasikan. Kemampuan penilaian yang dimaksud dalam hal ini adalah kemampuan melakukan penilaian dari source code secara kuantitatif sebagaimana telah dibahas pada Subbab 2.2. Dari ringkasan jenis penilaian pada Tabel II-7, dapat disusun daftar jenis penilaian yang dapat dilakukan Phobos pada Tabel III-4.
Beberapa jenis penilaian dari Tabel II-7 tidak diimplementasikan karena realisasi penilaian tersebut untuk berbagai bahasa pemrograman terlalu rumit atau tidak sesuai. Deteksi struktur kode yang berbahaya dan pengukuran jumlah instruksi dan memori tidak diimplementasikan karena realisasinya untuk aplikasi multibahasa terlalu rumit. Kompleksitas Henry dan Kafura tidak diimplementasikan karena pengukuran besaran aliran data tidak cocok digunakan untuk tugas pemrograman yang rata-rata berukuran kecil. Penilaian-penilaian yang berkaitan dengan struktur blok juga tidak diimplementasikan, karena struktur blok tidak dikenal dalam paradigma pemrograman fungsional.
Tabel III-4 Jenis penilaian otomatis Phobos
Jenis Penilaian Phobos
Aspek penilaian
Besaran Penilaian Kebutuhan Perangkat Lunak
Kebenaran sintaksis program Mengkompilasi program dan menangkap kesalahan kompilasi Keberadaan struktur kode yang
berpotensi menimbulkan bug. (tidak diimplementasikan) Ketepatan Sintaks &
Semantik
Pengujian dinamis
Menghitung persentase data uji benar dan menangkap runtime error
Lamanya eksekusi program Mengukur waktu yang diperlukan untuk eksekusi program
P ende ka ta n B lackb o x Efisiensi
Jumlah memori yang digunakan
program. (tidak diimplementasikan) SLOC Menghitung jumlah baris source
code yang diberikan K. Halstead (tidak diimplementasikan) K. Henry & Kafura (tidak diimplementasikan) Kompleksitas
K. Siklomatik Menghitung jumlah titik percabangan dalam kode Memeriksa keberadaan identitas file kode
Menghitung persentase jumlah baris komentar
Keberadaan keterangan pada kode
Menghitung persentase karakter dalam komentar
Menghitung rata-rata panjang baris
Proporsi Whitespace
Menghitung rata-rata jumlah karakter kosong dalam baris
Perimbangan Delimiter (tidak diimplementasikan)
Identifier yang bermakna Menghitung rata-rata panjang
identifier
Ketepatan Indentasi Menghitung persentase indentasi tepat P endeka ta n Whi te B ox Tipografi kode
Konvensi Spesifik Bahasa
Pemrograman (Tidak diimplementasikan)
Kebutuhan fungsional yang harus dipenuhi oleh autograder Phobos dijabarkan pada Tabel III-5. Sebagaimana telah dibahas pada analisis proses penilaian otomatis, skema penilaian dirancang sebagai salah satu masukan pada Phobos. Hal ini menyebabkan Phobos harus memiliki kemampuan untuk membuat dan mengubah skema penilaian. Jenis-jenis penilaian otomatis sebagaimana dijabarkan pada Tabel III-4 juga menjadi kebutuhan fungsional Phobos.
Tabel III-5. Spesifikasi Fungsional Phobos
Nomor SRS Fungsi Keterangan
PHB-SRS-F-01 Membuat definisi skema penilaian untuk tugas
Autograder dapat membuat definisi skema penilaian yang akan digunakan untuk proses grading. PHB-SRS-F-02 Memproses source code
program dan menangkap kesalahan sintaksis
Autograder dapat mengubah source code yang akan dinilai ke dalam pohon sintaks abstrak serta menangani dan mencatat kesalahan sintaks yang terjadi.
PHB-SRS-F-03 Menghitung persentase data uji benar dan menangkap runtime error
Autograder dapat mengeksekusi program
menggunakan data uji, memeriksa kebenaran hasil eksekusi program, menghitung proporsi kasus benar serta menangkap kesalahan saat eksekusi
PHB-SRS-F-04 Menghitung jumlah baris
source code yang diberikan
Autograder dapat menghitung jumlah baris source code (di luar komentar).
PHB-SRS-F-05 Menghitung jumlah titik percabangan dalam kode
Autograder dapat menghitung jumlah titik percabangan logika pada source code
PHB-SRS-F-06 Memeriksa keberadaan identitas file kode
Autograder dapat memverifikasi keberadaan identitas pada source code
PHB-SRS-F-07 Menghitung persentase komentar terhadap kode
Autograder dapat menghitung jumlah baris komentar dan rata-rata jumlah huruf komentar yang terkandung dalam source code
PHB-SRS-F-08 Menghitung rata-rata panjang identifier
Autograder dapat menghitung rata-rata panjang
identifier pada source code
PHB-SRS-F-09 Menghitung persentase indentasi tepat
Autograder dapat menghitung proporsi indentasi tepat pada source code
PHB-SRS-F-10 Mengukur lamanya eksekusi program
Autograder dapat mengukur waktu yang dibutuhkan
untuk eksekusi program PHB-SRS-F-11 Menghasilkan laporan
nilai serahan tugas
Autograder dapat menghasilkan laporan nilai (nilai & penjelasan) dari proses penilaian yang telah dilakukan terhadap serahan tugas. Laporan yang dihasilkan dapat berupa laporan individu maupun kolektif. PHB-SRS-F-12 Menghapus data hasil
proses penilaian
Autograder dapat menghapus hasil penilaian yang sudah tidak digunakan.
Kebutuhan fungsional yang telah ditetapkan dapat dipetakan kepada use case yang telah dibuat dalam model use case. Pemetaan antara kebutuhan fungsional dengan use case dapat dilihat pada Tabel III-6.
Tabel III-6. Pemetaan SRS terhadap Use-Case untuk Phobos
Nomor Use Case Nomor SRS
PHB-UC-01 PHB-SRS-F-01 PHB-UC-02 PHB-SRS-F-02 PHB-UC-03 PHB-SRS-F-11 PHB-UC-04 PHB-SRS-F-12 PHB-UC-05 PHB-SRS-F-03 PHB-UC-06 PHB-SRS-F-04 PHB-UC-07 PHB-SRS-F-05 PHB-UC-08 PHB-SRS-F-06 PHB-UC-09 PHB-SRS-F-07 PHB-UC-10 PHB-SRS-F-08 PHB-UC-11 PHB-SRS-F-09 PHB-UC-12 PHB-SRS-F-02
3.3.3 Spesifikasi Non Fungsional Phobos
Proses penilaian yang dilakukan oleh Phobos harus efisien, karena Phobos akan digunakan dalam kelas dengan ratusan siswa. Selain itu, meskipun dalam Tugas Akhir ini masih bersifat batch processing, Phobos juga direncanakan agar suatu saat dapat dikembangkan menjadi sistem interaktif. Kebutuhan non-fungsional untuk autograder Phobos dijelaskan secara lebih mendetil pada Tabel III-7.
Tabel III-7. Kebutuhan Non-Fungsional Phobos
Nomor SRS Spesifikasi Keterangan
PHB-SRS-NF-01 Aksesibilitas Layanan autograder dan hasil penilaiannya dapat diakses dari komputer manapun yang terhubung pada internet. PHB-SRS-NF-02 Efisiensi Autograder harus mampu menilai source code yang
mencapai ratusan dalam waktu yang dapat ditoleransi, yaitu tidak lebih dari setengah hari kerja untuk kelas berisi seratus mahasiswa.
PHB-SRS-NF-03 Ekstensibilitas Autograder dapat dikembangkan lebih lanjut agar dapat menambahkan jenis penilaian atau menangani bahasa pemrograman lain tanpa mengembangkan ulang seluruh
autograder.
3.3.4 Deskripsi Arsitektural Phobos
Pada Subbab ini akan dibahas mengenai rancangan arsitektural Phobos, dekomposisi komponen, pembagian tanggung jawab dan proses yang dilakukan oleh tiap komponen. Deskripsi arsitektural sistem Phobos terkait dengan proses penilaian dapat dilihat pada Gambar III-7. Phobos secara umum terdiri dari beberapa tingkatan (tier) : presentation tier, logic tier dan data tier. Antarmuka sistem terhadap pengguna pada presentation tier ditangani oleh web browser pada komputer klien. Pada logic tier, terdapat dua komponen utama, yaitu aplikasi front-end dan engine penilai otomatis. Pada data tier, terdapat persistent storage, di mana disimpan seluruh skema penilaian dan laporan nilai yang dihasilkan.
Aplikasi front-end bertindak sebagai antarmuka aplikasi Phobos dengan protokol HTTP menggunakan PHP. Komponen front-end dirancang sebagai aplikasi web agar aplikasi dapat diakses dari komputer manapun yang terhubung dengan internet, sebagaimana telah disebutkan dalam kebutuhan non fungsional Phobos. PHP dipilih sebagai bahasa pemrograman untuk pengembangan aplikasi web karena PHP telah tersedia pada kebanyakan web server dan LMS milestone dikembangkan dengan menggunakan bahasa PHP. Tanggung jawab utama aplikasi front-end adalah menerima perintah dan masukan dari instruktur dan menampilkan respon yang sesuai dengan perintah yang diterima. Perintah dari instruktur yang ditangani yaitu membuat skema penilaian baru, memulai proses penilaian, meminta laporan nilai atau menghapus data penilaian tertentu.
HTTP Logic Tier Presentation Tier Data Tier Persistent Storage Server dengan Instalasi Phobos Komputer Client Instruktur Web Browser Aplikasi Front-End
Engine Penilai Otomatis
Oracle Whitebox
Markers Manager
Gambar III-7 Deskripsi Arsitektural Phobos
Autograder engine bertindak sebagai pengendali pada proses penilaian. Sebagaimana telah dibahas pada Subbab 3.3.2, salah satu kebutuhan pada fungsional Phobos adalah kemampuan memproses source code program (PHB-SRS-F-02), sehingga dibutuhkan proses analisis leksikal dan analisis sintaks. Phobos akan menggunakan generator parser Antlr untuk membantu melakukan kedua proses tersebut. Selain itu, proses penilaian akan melibatkan analisis pohon sintaks abstrak, sebagaimana yang dilakukan pada pemeriksa pola Checkstyle. Kedua perangkat lunak tersebut dikembangkan dalam bahasa Java, sehingga komponen autograder engine akan juga dikembangkan menggunakan bahasa Java. Komponen autograder engine sendiri terdiri dari beberapa subsistem berdasarkan tanggung jawabnya dalam proses penilaian. Subsistem yang terdapat dalam komponen autograder engine yaitu subsistem Manager, Oracle dan WhiteboxMarkers. Ikhtisar pembagian tanggung jawab, masukan beserta keluaran dari masing-masing subsistem tercantum pada Tabel III-8.
Tabel III-8 Tanggung Jawab Setiap Subsistem pada Autograder Engine Phobos, beserta masukan yang dibutuhkan dan keluaran yang dihasilkan
Nama subsistem
Tanggung jawab subsistem Input yang
dibutuhkan
Hasil proses eksekusi
Membuat dan menyimpan definisi skema penilaian
[PHB-SRS-F-01]
- Nama dan deskripsi tugas
- Bahasa pemrograman pada source code target deteksi
- Jenis-jenis penilaian & bobotnya. - Data uji yang akan digunakan
File definisi skema penilaian
Membangkitkan prosesor bahasa pemrograman yang digunakan [PHB-SRS-F-02]
File definisi skema penilaian
Prosesor bahasa pemrograman (interpreter) Menjalankan proses penilaian.
[PHB-SRS-F-02]
- Interpreter - File atau direktori
source code yang hendak dinilai
Data hasil penilaian
Membangkitkan laporan penilaian [PHB-SRS-F-03]
Data hasil penilaian Laporan nilai
Manager
Menghapus hasil penilaian apabila tidak lagi dibutuhkan
[PHB-SRS-F-04]
Data nilai yang hendak dihapus
Status keberhasilan penghapusan data
Oracle Penilaian eksekusi program
(Memroses source code dan mengeksekusi program, menguji kebenaran keluaran program, menghitung waktu eksekusi dan menangkap semua kesalahan yang terjadi dalam interpreter/eksekusi) [PHB-SRS-F-05]
- Prosesor bahasa pemrograman - Source code
- Data uji (dari file skema penilaian)
Laporan hasil eksekusi
Whitebox Markers
Penilaian whitebox (Memroses
source code dan melakukan penilaian terhadap pohon sintaks abstrak yang dihasilkan)
[PHB-SRS-F-06, PHB-SRS-F-07, PHB-SRS-F-08, PHB-SRS-F-09, PHB-SRS-F-10, PHB-SRS-F-11, PHB-SRS-F-12] - Prosesor bahasa pemrograman - Source code - Jenis-jenis penilaian & bobotnya. (dari def. skema penilaian)
Laporan hasil analisis source code
Karena komponen front-end dan autograder engine dikembangkan menggunakan bahasa pengembangan yang berbeda, komunikasi antara satu komponen dengan komponen yang lain akan dilakukan menggunakan XML. XML juga digunakan sebagai format untuk skema penilaian dan laporan penilaian dalam penyimpanan persisten. Format XML dipilih karena independen terhadap bahasa pemrograman dan fleksibel. XML juga dipilih karena Phobos diharapkan akan dapat dikembangkan pada masa depan ke dalam konteks penggunaan lainnya, sesuai dengan kebutuhan non fungsional ekstensibilitas pada Subbab 3.3.3. Detil perancangan penyimpanan persisten pada Phobos akan diberikan pada Subbab 4.3.
3.3.4.1 Manager
Subsistem Manager bertanggung jawab untuk mengendalikan jalannya proses penilaian oleh Phobos secara keseluruhan. Tanggung jawab Manager mencakup membuat dan menyimpan skema penilaian, membangkitkan prosesor bahasa pemrograman yang digunakan, menjalankan proses penilaian, membangkitkan laporan nilai, dan menghapus hasil penilaian yang tidak digunakan lagi.
Tanggung jawab pertama subsistem Manager adalah manajemen definisi skema penilaian. Definisi skema penilaian, sebagaimana telah dibahas pada Subbab 3.2.2, merupakan skenario proses penilaian, yang berisi jenis-jenis penilaian yang akan dijalankan terhadap program, termasuk data uji bila terdapat proses penilaian eksekusi. Subsistem Manager akan mengolah masukan berupa nama tugas dan deskripsi tugas, bahasa pemrograman yang akan digunakan, jenis-jenis penilaian beserta data uji dari instruktur, dan kemudian menyimpannya dalam bentuk XML dalam penyimpanan persisten. Subsistem Manager juga bertanggung jawab untuk membaca definisi skema penilaian XML dari penyimpanan persisten untuk kemudian diubah atau digunakan dalam proses penilaian.
Tanggung jawab kedua subsistem Manager adalah pembangkitan prosesor bahasa pemrograman yang digunakan. Definisi bahasa pemrograman adalah detil cara interpretasi untuk bahasa pemrograman tertentu yang dibutuhkan agar source code dapat diproses. Karena Phobos dirancang agar dapat menangani bahasa pemrograman yang beragam, maka pembangkitan prosesor bahasa pemrograman dilakukan secara dinamis, dengan kelas khusus untuk masing-masing bahasa pemrograman. Menggunakan prosesor bahasa pemrograman yang dibangkitkan secara dinamis ini, Oracle dan WhiteboxMarkers akan dapat melakukan penilaian terhadap source code.
Tanggung jawab ketiga subsistem Manager adalah untuk mengendalikan jalannya proses penilaian oleh subsistem lain. Manager akan mendelegasikan proses penilaian blackbox kepada subsistem Oracle, memberikan masukan berupa data uji, pemroses bahasa dan source code kepada subsistem tersebut. Manager akan mendelegasikan proses penilaian whitebox kepada subsistem WhiteboxMarkers, memberikan masukan berupa prosesor bahasa pemrograman, source code dan daftar jenis-jenis penilaian kepada subsistem tersebut. Manager akan menerima laporan dari masing-masing subsistem dan menyimpannya ke dalam penyimpanan persisten menggunakan format XML.
Tanggung jawab lain dari subsistem Manager adalah manajemen data hasil penilaian. Subsistem Manager bertanggung jawab menghitung nilai dari hasil pengukuran Oracle dan WhiteboxMarkers yang telah tersimpan dalam penyimpanan persisten. Manager kemudian menyusun laporan nilai dari hasil perhitungan tersebut. Laporan yang disusun dapat berupa laporan nilai individu maupun laporan nilai kolektif seluruh source code yang dikumpulkan untuk satu tugas. Laporan yang telah disusun akan kemudian dikirimkan dalam bentuk XML kepada komponen aplikasi front-end. Subsistem Manager juga bertanggung jawab menangani penghapusan data hasil penilaian yang tidak lagi digunakan oleh instruktur.
3.3.4.2 Oracle
Subsistem Oracle bertindak sebagai penilai blackbox, sebagaimana telah dijelaskan pada Subbab 2.2.1.3. Subsistem ini menerima masukan berupa source code, source processor dan data uji dari subsistem Manager. Subsistem Oracle menghasilkan laporan hasil eksekusi dan memberikannya kembali kepada Manager.
Subsistem Oracle menerima source code dan mengeksekusinya menggunakan prosesor bahasa pemrograman. Eksekusi source code akan menggunakan masukan dari data uji dari skema penilaian yang telah diberikan oleh Manager. Oracle kemudian mencocokkan keluaran program yang sedang diuji dengan data keluaran seharusnya dari data uji; serta mencatat waktu eksekusi program. Laporan persentase data uji yang berhasil ditangani dengan tepat dan waktu eksekusi inilah yang kemudian diberikan Oracle pada Manager.
Oracle juga bertanggung jawab menangkap semua kesalahan yang terjadi, baik dalam tahap pemrosesan maupun eksekusi program. Kesalahan sintaktik dibangkitkan apabila Oracle menerima pesan kesalahan dari prosesor bahasa pemrograman. Kesalahan eksekusi dibangkitkan apabila waktu eksekusi program terlalu lama (untuk menangani keadaan program dalam blocking state atau infinite loop) atau menghasilkan exception yang tidak ditangani. Oracle juga bertugas untuk melepaskan resource yang mungkin tersisa dari eksekusi program. Kesalahan-kesalahan yang terjadi akan kemudian dilaporkan kepada Manager.
Jika di masa depan Phobos hendak dikembangkan untuk memiliki kemampuan penilaian eksekusi menggunakan data uji yang berasal dari sumber lainnya, hanya subsistem Oracle yang perlu diubah. Oracle juga dirancang sebagai subsistem terpisah untuk mengisolasi kesalahan-kesalahan yang mungkin terjadi pada saat eksekusi program yang sedang diuji.
3.3.4.3 WhiteboxMarkers
Subsistem WhiteboxMarkers melakukan penilaian besaran kualitatif source code, sebagaimana telah dibahas dalam Subbab 2.2.1.2. Subsistem ini menerima masukan berupa source code, source processor dan daftar jenis-jenis penilaian analitik dari subsistem Manager. Subsistem WhiteboxMarkers kemudian menghasilkan laporan nilai serahan tugas untuk kembali diserahkan kepada subsistem Manager.
Subsistem WhiteboxMarkers membaca source code dan mengubah source code tersebut menggunakan source processor ke dalam representasi antara pohon sintaks abstrak (PSA). PSA memungkinkan pengukuran besaran-besaran analitik yang berhubungan dengan kompleksitas dan tipografi source code, seperti kompleksitas siklomatik atau rata-rata panjang baris komentar. Laporan proses penilaian inilah yang kemudian akan diberikan WhiteboxMarkers kepada Manager.
Jika di masa depan Phobos hendak dikembangkan untuk menangani jenis penilaian whitebox lainnya, hanya subsistem WhiteboxMarkers saja yang perlu dimodifikasi. Jenis penilaian baru dapat ditambahkan dengan mengimplementasikan kelas penilai baru.
3.3.5 Analisis Prosesor Bahasa Pemrograman dalam Phobos
Penilaian eksekusi program merupakan bagian yang penting dari proses penilaian dalam Phobos. Hal inilah yang menyebabkan kemampuan untuk memproses source code program (PHB-SRS-F-02) dan menguji kebenaran program (PHB-SRS-F-03) melalui uji eksekusi menjadi kebutuhan fungsional yang sentral. Kedua kebutuhan fungsional ini mengharuskan Phobos memiliki kemampuan untuk memproses bahasa pemrograman, dengan menjadikan prosesor bahasa pemrograman sebagai salah satu bagian dalam sistem ini.
Sebagaimana disebutkan dalam Subbab 2.3.2, teknik implementasi bahasa pemrograman yang umum digunakan adalah kompilasi dan interpretasi. Kompilasi merupakan teknik implementasi bahasa pemrograman yang umum digunakan karena eksekusi kode biner hasil kompilasi jauh lebih cepat dibandingkan dengan eksekusi dengan interpretasi. Di dalam kompilasi, program dieksekusi sebagai proses mandiri dengan resource sistem operasi yang terpisah, sementara dalam interpretasi, eksekusi dijalankan sepenuhnya dalam proses interpreter. Karena itu, interpreter dapat menangani kesalahan-kesalahan yang terjadi dalam proses eksekusi kode dan menghasilkan laporan dari kesalahan saat eksekusi tersebut dengan lebih baik. Karakteristik-karakteristik ini menyebabkan interpretasi memiliki potensi nilai
pedagogik yang lebih baik, khususnya untuk memberikan umpan balik mengenai kesalahan dalam eksekusi program. Sebagai bagian dalam suatu sistem penilai, interpretasi juga memiliki keamanan yang lebih tinggi karena interpreter dapat mengawasi eksekusi program secara penuh. Eksekusi kode biner hasil kompilasi tidak dapat diawasi sepenuhnya, sehingga jika autograder menggunakan kompilator, perlu dibuat pengamanan terpisah yang kuat. Oleh sebab itulah, pemrosesan source code dalam Phobos menggunakan teknik interpretasi.
Dalam proses penilaian whitebox, Phobos akan membangkitkan pohon sintaks abstrak dari source code. Interpreter, sebagaimana telah dibahas dalam Subbab 2.3.3, menjalankan eksekusi berdasarkan pohon sintaks abstrak yang dibangun dari hasil parsing terhadap source code. Dengan mengembangkan interpreter khusus untuk melakukan eksekusi berdasarkan pohon sintaks abstrak, source code hanya perlu di-parse satu kali saja. Interpreter dapat menyimpan pohon sintaks abstrak hasil parsing dan kemudian langsung melakukan eksekusi program berdasarkan pohon tersebut. yang mendasari penggunaan interpreter yang dikembangkan sendiri untuk kepentingan penilaian otomatis Phobos, tidak menggunakan komponen yang sudah tersedia.
Karena interpreter Phobos digunakan untuk kepentingan penilaian, interpreter dirancang dengan memperhatikan unsur-unsur pengajaran pemrograman, seperti misalnya dengan merancang interpreter untuk mendeteksi konstruksi loop yang salah, ekspresi boolean yang tidak berguna, atau infinite loop dalam source code berbahasa Pascal. Interpreter spesifik ini dapat dirancang untuk melakukan inspeksi terhadap kode sebagaimana yang dilakukan oleh penilai manusia.
