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 System milestone dan autograder Phobos 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.
III-2
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
InstrukturMahasiswa
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.
III-3
Pembangunan autograder Phobos 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.
III-4
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 autograder Phobos 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.
III-5
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
III-6
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.
III-7
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.
III-8
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 autograder Phobos.
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 case Phobos 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.
III-9
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.
III-10
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 :
III-11
1. Instruktur membuat definisi skema penilaian pada form aplikasi dan mengirimkannya
kepada autograder Phobos melalui web browser.
2. Browser mengirimkan data definisi skema penilaian kepada autograder Phobos
3. Autograder Phobos 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 autograder Phobos.
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 Autograder Phobos tetap
dipertahankan.
4. Autograder Phobos mengirimkan status bahwa penilaian telah selesai dilakukan.
5. Web browser menampilkan pesan bahwa penilaian otomatis telah selesai dilakukan.
III-12
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 autograder Phobos.
3. Autograder Phobos melakukan query pada persistent storage untuk mengambil isi
laporan dan mengatur format laporan nilai dalam bentuk HTML.
4. Autograder Phobos mengirimkan laporan nilai kepada pengguna.
5. Web browser menampilkan laporan nilai kepada pengguna.
Komputer yang terinstalasi Phobos
Phobos
Instruktur
45
Komputer user
HTTP
21
3Web
BrowserPersistent Storage
Gambar III-5 Skenario penggunaan Phobos untuk melihat laporan nilai
III-13
Skenario penggunaan autograder Phobos 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 autograder Phobos.
3. Autograder Phobos menghapus data hasil penilaian dari persistent storage.
4. Autograder Phobos 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
Autograder Phobos 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.
III-14
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 Pe
ndek
atan
Bla
ckbo
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
Pend
ekat
an W
hite
Box
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.
III-15
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
III-16
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.
III-17
HTTP
Logic Tier
Presentation Tier
Data Tier
Persistent Storage
Server denganInstalasi Phobos
KomputerClient
Instruktur
Web Browser
AplikasiFront-End
Engine Penilai Otomatis
Oracle WhiteboxMarkers
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.
III-18
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.
III-19
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.
III-20
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.
III-21
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
III-22
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.