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.